objects/object classes: new features from a newbie-friendly perspective

[jeeswg]

- I'm pretty much ready to do an object classes tutorial. I'm posting this link in case anybody would like to write a very simple class that demonstrates their preferred object class coding style (so that I can mention variables styles and don't impose my own view in any tutorial).
object classes: coding style - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=48938
- Also has anything been said about the three/four pillars of OOP anywhere? Inheritance (use 'extends'), encapsulation (AHK has no public/private distinction), polymorphism (relevant to AHK?), abstraction. I.e. to do a tutorial it might be good to make comparisons with other languages.

[nnnik]

- A key feature is that when you do obj.key := {}, obj and obj.key should be of the same class, and obj.key should contain information about obj (its parent object).

Ive missed the recent posts you made, due to not having time. I dont understand what you mean here.
Under very weird/rare conditions I want to activate this feature thats there for no reason and I provide no explination why these rare conditionshave anything to do with the feature.
I'm sorry but this is not convincing.

[jeeswg]

- I've changed my header in my 2nd post to this:
IMPORTANT FUNCTIONALITY TO POTENTIALLY CONSIDER/FACILITATE
(BUT THAT COULD JUST BE ACHIEVED CUSTOM CLASSES)
- So basically: here are some things to consider, but I'm actually *not sure* or open-minded about how/if they should be implemented. And also, sometimes implementing something that makes X a bit easier to achieve, is preferable to implementing something esoteric that achieves X directly.
- A workaround is to have a __Set meta-function, where if an object is specified (as the value for the key), instead of creating a built-in AHK object, you create an object with the same class as the class (using the new keyword), and populate it with any keys if necessary.
- For some situations, a workaround is: obj.key := new %class%.

[nnnik]

Yeah but I'm still not sure what X exactly is and why you want to have it and why its better to implement it in the AHK source instead of your class. Also your solution sounds very esoterical to me.

[jeeswg]

RELEGATED IDEAS / MODES / STILL A PROBLEM
- @nnnik: Re. your last two points I basically agree with you (that some functionality could just be implemented via custom classes).
- I've been ironing out my proposals, and keeping them up-to-date in post 2.
objects/object classes: new features from a newbie-friendly perspective - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 83#p214283
- I've just renamed one of the sections to 'RELEGATED IDEAS', those are ideas to ponder, everything else is more concrete.
- One idea had been to consider built-in arrays with different modes, but it's tempting to ditch the whole thing. However, people getting in a muddle because hex digits aren't returned in the expected order (the numeric/string key name issue), or because obj.HasKey() fails because the key 'HasKey' exists (and the user wonders what other method name quirks are there), I'm tempted to think that some sensible compromise/solution can be found.

CHANGING/SWAPPING ABOUT IDEAS
- Even the smallest addition can have ripple effects, making all sorts of new things easier/possible. This is true re. the AHK v1.1.28/29 test build.
Test build - Obj.Count(), OnError(), long paths, experimental switch-case - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 24&t=47682
- I've discovered some information re. which takes priority: keys/properties/methods, the obj := new %class% functionality, figured out some hacks etc, all of this has changed the landscape of the feature proposals.

DISCUSSIONS RE. RELEGATED IDEAS
- I haven't heard much discussion of obj.a.b.c.d.e := value, should obj or obj.a.b.c.d handle the assignment of the value. Have you not come across this issue? Ultimately though, as is always the way, a roundabout complicated custom class can give you whatever behaviour you want. And maybe that's good enough. But I think it's at least something to think about. Whether *perhaps* something beyond 'leave things are they are', should be considered. [At the moment I'm happy to do nothing re. this.]
- Also if obj.a.b.c.d was to ask obj what to do, each key needs to know what its parent is. Again, storing the parent could ultimately just be achieved by using a custom class, without needing any new functionality. [However, storing special object information, without polluting the keys, is an important consideration.]
- I thought up a hack for obj.key := {}, that if obj is of a custom class, and the __Set meta-function sees that the proposed value is an object, and if all of the keys are stored outside the object in a global object, obj.key will be made to be the same class as obj (instead of a built-in array). [No need for any new functionality here, and I'm OK with that, however, the whole thing is pretty complicated.]
- The family trees concept is part of a larger basic concept, how can we store special information about an object, outside the object itself so that it doesn't interfere with key/property/method names. And even further, if we want to always invoke the __Get/__Set meta-functions when assignments are made, currently we must store all of the information in an external global object. A possible solution would be: information is stored in obj.key, but whenever you try to access obj.key you are instead passed to a property called 'key', and 'key' acts as the go-between. [That would need properties to take priority over keys.] Another idea, is ... can we have some kind of secondary/hidden/auxiliary/store object associated with every object.

[nnnik]

- I haven't heard much discussion of obj.a.b.c.d.e := value, should obj or obj.a.b.c.d handle the assignment of the value. Have you not come across this issue? Ultimately though, as is always the way, a roundabout complicated custom class can give you whatever behaviour you want. And maybe that's good enough. But I think it's at least something to think about. Whether *perhaps* something beyond 'leave things are they are', should be considered. [At the moment I'm happy to do nothing re. this.]

If you check a few years back you might even find a post about this in the old forums - I think lexikos responded something like:

obj.a.b.c.d.e is essentially the same as (((((obj).a).b).c).d).e which would be similar to: e := ( d := ( c := ( b := ( a := ( obj ).a ).b ).c ).d ).e which is esentially like:

Code: Select all

a := obj.a
b := a.b
c := b.c
d := c.d
e := d.e

On the last line do you really want to trigger the eent of the first obj?
If you really want to triggr obj when accessing it's keys use obj["a","b","c","d","e"]instead.

- The family trees concept is part of a larger basic concept, how can we store special information about an object, outside the object itself so that it doesn't interfere with key/property/method names. And even further, if we want to always invoke the __Get/__Set meta-functions when assignments are made, currently we must store all of the information in an external global object. A possible solution would be: information is stored in obj.key, but whenever you try to access obj.key you are instead passed to a property called 'key', and 'key' acts as the go-between. [That would need properties to take priority over keys.] Another idea, is ... can we have some kind of secondary/hidden/auxiliary/store object associated with every object.

If you write a library for creating such a private object once you can reuse it across all projects and there won't be a need to built it into AutoHotkey.

- Even the smallest addition can have ripple effects, making all sorts of new things easier/possible. This is true re. the AHK v1.1.28/29 test build.
Test build - Obj.Count(), OnError(), long paths, experimental switch-case - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 24&t=47682

So true. Also see:
https://autohotkey.com/boards/viewtopic ... 74&t=48740

[jeeswg]

- Thanks for the info re. obj.a.b.c.d.e.
- Btw I suppose that this isn't possible: obj.%method%()? To dynamically call a method. I did find a way however:

Code: Select all

q:: ;dynamic method call
oArray := ["a", "b", "c"]
vMethod := "Length"
MsgBox, % oArray.Length() ;3
;MsgBox, % oArray.%vMethod%() ;Error: Ambiguous or invalid use of "."
MsgBox, % oArray[vMethod]() ;3
MsgBox, % oArray[vMethod] ;(blank)
return

Do show me if it's in the documentation somewhere (I did do a search).
- I wondered if an option, placed inside a property(/method), could be an idea, it would specify that it couldn't be overridden by a key. (Just an idea.)

[A_AhkUser]

Hi jeeswg,

Do show me if it's in the documentation somewhere (I did do a search).

Unless I'm mistaken on the topic, this is actually mentionned in the documentation:

Call a method with a computed method name:
ReturnValue := Object[MethodName](Parameters)

Btw, you can also do:

Code: Select all

MsgBox, % ObjBindMethod(oArray, vMethod).() ;3

Cheers

[jeeswg]

- @A_AhkUser: Very nice, thanks. A-ha, computed method name, I wasn't expecting the word 'computed'.

- In this thread, it was mentioned, for linear arrays, the slowness of using obj[A_Index] v. a for loop.
AHK v2 Migration. What is the syntax for WinGet ControlList? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=50379

- Sometimes I would like to loop through an associative array, as though it were a linear array, using a for loop, for improved speed. The problem is that you have to determine which keys to ignore, and to add in handling for keys that don't exist. Well, I've attempted this below, using listing the keys as an example. Both functions are equivalent, the first should be faster, while the second is shorter.

Code: Select all

;a 'linear array' for loop
q:: ;object list keys, 'linear array keys' only
oArray := {x:"x"}
MsgBox, % oArray.Length() ;0
MsgBox, % JEE_ArrListSimple(oArray)
MsgBox, % JEE_ArrListSimpleAlt(oArray)

oArray := {-5:"z", 1:"a", 3:"c", 10:"j", x:"x"}
MsgBox, % oArray.Length() ;10
MsgBox, % JEE_ArrListSimple(oArray)
MsgBox, % JEE_ArrListSimpleAlt(oArray)
return

;==================================================

;lists keys in a linear array
;note: lists defined/undefined keys between 1 and MaxIndex
;note: does not list keys outside that range
JEE_ArrListSimple(oArray, vSep:=" ")
{
	if !(vLen := oArray.Length())
		return
	vIndex := 0
	for vKey, vValue in oArray
	{
		if (vKey < 1)
			continue
		Loop, % vKey - vIndex - 1
			vIndex += 1
			, vOutput .= vIndex vSep "`r`n"
		vIndex += 1
		, vOutput .= vKey vSep vValue "`r`n"
		if (vKey = vLen)
			break
	}
	return SubStr(vOutput, 1, -2)
}

;==================================================

JEE_ArrListSimpleAlt(oArray, vSep:=" ")
{
	Loop, % oArray.Length()
		vOutput .= A_Index vSep oArray[A_Index] "`r`n"
	return SubStr(vOutput, 1, -2)
}

;==================================================

[nnnik]

You will have a speed loss when storing different elements in the same array as key value pairs since you have the overhead of having to split the values.
I would rethink my design and consider using separate objects.