- OK, by 'not equivalent', I think that maybe you just meant
:= {} and
:= new MyClassAppendWhenSet are not equivalent, which, yes, is true.
- And by 'changes the behaviour', I think you mean that we would then change the behaviour of __Set() for all child objects (they would be custom not standard arrays).
- We had a discussion about things being misunderstood on the Internet once before, I believe. With this discussion I want to get every detail right, so I don't mind if you add 2 sentences to every 1 sentence to make things clearer. Also, this will then make follow-up questions less likely.
- By 'assigns to the key you expect it to', I was thinking of what I might call a 'custom array', it would work just like a standard AHK array would, but with subtle differences. This would be something that somebody else could use, and would store keys in exactly the place that they would normally.
- That 'sub-classing arrays of arrays' example is great, it seems to have a neat hack that avoids the more convoluted approach of using 'new' every time. This is exactly the sort of thing you can only do if you go for the deep/fundamental understanding that I'm aiming for in my tutorial. You mention trying to 'fix' it, I'm not really clear what's wrong with it.
==================================================
WRITING TUTORIALS
- Thanks for the encouraging words re. a tutorial.
- I'll give it a go, but I am concerned about making any number of misstatements (which obviously I'm trying to avoid).
- I think two important principles are (1) bottom-up/fundamentals/theoretical, (2) practical. I aim to combine the two.
- Two potential problems in other tutorials that I'm trying to avoid.
- THEORETICAL. Some people can think they're covering 'fundamentals' when they talk about (valid) buzzwords like 'class' and 'prototype' without really explaining anything or giving concrete examples. Thus you explain nothing, and have the false perception of depth.
- PRACTICAL. You start off with some basic classes for window/file information, something that I, myself, intend to do. However, as we've seen in some of the classic links on this page, there are some key details, fundamentals, that really you need to know, or would very much benefit from knowing. The 'right'/best way to do something, is often a hack, a perfectly acceptable, uncontroversial hack. With object classes, you can't get far without fundamentals.
==================================================
SURPRISES AS A NEWCOMER TO CUSTOM CLASSES
- Coming to custom classes without any preconceptions. Three simple things that I thought might be mainstream. An array where you can have methods/keys with the same name. Read/Write methods, that work every time you read or write to a key (whether it exists or doesn't exist). The ability to refer back to parent/ancestor objects whenever you do anything.
- BArray, which is relevant to the methods/keys concern.
obj.HasKey() fails for all keys if a key called HasKey exists - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 15#p148015
Possible AHK bug - the word "base" is missed in an array for-loop - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 27#p113927
==================================================
AHK V2 CHANGES
- I went over the v2-changes/v2-thoughts pages again, after having tried to study the A-Z of objects.
- 2 classic changes: roughly speaking: a key name that looks numeric is stored as a numeric key, for k,v in object: k,v are cleared once the loop ends.
- Is '__Set' being replaced with 'Set' etc. [EDIT:] But wouldn't 'Delete' and '__Delete' clash? [EDIT:] It looks like some methods currently have two possibilities e.g. HasKey and _HasKey, although I didn't find '_HasKey' in the documentation anywhere.
v2-changes
https://autohotkey.com/v2/v2-changes.htm
All built-in methods of Objects and SafeArrays no longer support the _ (underscore) prefix, except _NewEnum, which now requires it (for compatibility with COM objects). ObjNewEnum(x) is still equivalent to x._NewEnum() for Objects.
- This idea is interesting, it touches on something I mentioned earlier.
v2-thoughts
https://autohotkey.com/v2/v2-thoughts.htm
new MyClass[a,b,c] could be reserved as a more convenient way to initialize a specialised array/collection type (new MyClass{a:b} is already "reserved" by way of being treated as a syntax error).
- A way to create a custom WinMove function, and refer to the built-in WinMove function etc would be very useful.
If base is reserved everywhere, it could be used for calling an overridden built-in function (such as base.WinMove(x, y) in a redefinition of WinMove).
- Anyone for Len, that is oArray.Len() and/or oArray.Length(). I thought it would be Len to match StrLen.
==================================================
CUSTOM CLASSES V. FUNCTIONS
[EDIT: Section rewritten.]
- Custom classes, if I were to make more use of them, I would see three areas:
- An array that is convenient as a tool when writing scripts, e.g. a variant of the built-in standard AHK array, e.g. case sensitive or case insensitive arrays, with additional enumerator possibilities: alphabetical order, get key/value pairs in reverse order, or in the order they were added to the array.
- An array for use with other scripts (or programs), so, a COM object.
- Specific, but rare, situations. Perhaps for use in a custom file/registry loop.
- I would generally recommend people to write libraries in a dual object class/stand-alone functions way. You can use the functions as stand-alone functions, without using the class, and the class makes use of the stand-alone functions for most of its functionality.
- Some problems I see where people use an object class library, when a function library would be better.
- Classes add additional difficulty/complexity where it isn't needed, and errors.
- If I write a function that handles an hWnd, that is more universal, if I write a class that only works with a custom window/control object, that is less useful.
- With separate classes for each type of GUI control, I could end up with similar but inconsistent objects. I would especially recommend using stand-alone functions for GUI controls, with a class mostly as a simple wrapper, for anyone who wants it. Generally I would say that GUI functions should stick pretty closely to the window messages that they are probably based on.
- Often there are quirky things in the class implementations that I see. I am more likely to find things I dislike in a class, than in a simple stand-alone function.
- Also, often you get a class that 'tries to do too much', something that simple stand-alone functions are less likely to do. Imagine that the user simply doesn't like your grand scheme, are there simple functions that they can repurpose for their own goals.
- With separate functions you can take out only the bit of the code that you need for some other project.
- Classes are more convoluted than separate functions.
- Functions are easier for translating to/from other projects that may not even use AutoHotkey.
- Let's you say you want to understand how to get from A to B, you have to jump about through various class methods, diagnosing the code. E.g. WinClip, a great script, can be quite hard to follow, and instead of using WinClip, I use separate functions that perform a similar role. Comparing certain simple functions that I have written, with how they are split up across methods in WinClip, WinClip makes some quite straightforward things appear exceedingly complicated.
- It's harder to debug the code in classes, and it's often undesirable to try to add new features.
- Speaking more generally about some of the libraries that I have seen, I think that some people have an unfortunate predilection for, a blind ill-considered ideological bias in favour of, object classes, where they're not wanted or needed.
.
.
.
I do not understand 
.