[a104] are builtin classes protected against accidental overwriting? Topic is solved

[Helgef]

I was perfectly happy with oArray.__Class = "Array" or Type(oArray) = "Array", I don't see the need for the check to be done against a *variable*.

So I guess you didn't read the documentation on is.

If Type is an object, the result is true if Value is an object derived from Type, directly or indirectly.

[jeeswg]

- @Helgef: I think you're missing the point. Do you want these to be prohibited variable names:
Array/Class/Map/Object, Gui/Menu/File, custom class names. See:
[a104] are builtin classes protected against accidental overwriting? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=82&t=67257&p=294978#p294978
- This issue of (/doubts re.) 'do we really want Gui/Menu/File etc to be prohibited variable names', appears to be holding up AHK v2 development, and for me the answer is: the instincts/doubts are right, we don't want them to be prohibited variable names. So what do we do? Well I made some suggestions earlier in the thread.
- (To your point. Yes, I knew that: in AHK v2, 'is' supports object and byref.)

- @gregster: Fair point. Although we all type things in occasionally right?

[Helgef]

I already said I didn't get your point.

To your point. Yes, I knew that: in AHK v2, 'is' supports object and byref.

That wasn't my point,

the result is true if Value is an object derived from Type, directly or indirectly.

---

Do you want these to be prohibited variable names:
Array/Class/Map/Object, Gui/Menu/File, custom class names.

They aren't prohibited, as with any variable, you can declare them local if you want to use them locally without overwriting the super global variable. Having predefined super global variable's isn't a big problem, but it is harder to add new ones without breaking scripts.

Cheers.

[jeeswg]

- Is this your point ... The 'is' operator doesn't just compare the types of 2 objects, but the ancestry of 2 objects. And it can't be done in any other short-ish way in AHK currently? Crucially though, how is that usually done in other programming languages?
- (The functionality of 'is obj' is thus somewhat curious/unintuitive, if you had a function to perform that role, what would be a good descriptive name for it?)
- (Btw the use of 'directly or indirectly' is a bit confusing also, if C is derived from B, and B is derived from A, C is a *direct* descendant of A.)

- It's nice that we can override the class vars *within functions*, but the vast majority of AHK code is done in the global namespace, where the variable names would be(/currently are) prohibited.
- How would you feel if loadtime class variables were simply removed? You'd create a temporary class variable via a function if you wanted it. I would definitely prefer it that way, as I found when using Coco's JSON library as an example... I couldn't use JSON as a regular variable, and when I added local to all of my functions, I had to add global to all of my uses of the JSON variable. And if I'd obtained the JSON variable via a function, in all of my functions, none of that would have happened.
- And as a newbie, it's more intuitive that variables are variables, and there aren't special variables that you can't/'mustn't' overwrite (other than the clearly labelled A_ variables). It was unintuitive also that the mere existence of a class created a variable. Cf. functions where you have to call the function to make anything happen. (Functions that can quietly sit in the included libraries with no effect on the script.)
- Also, this seems to go against the AHK v2 trend of separating namespaces e.g. keys/properties/methods, by combining variable names/class names. Cheers.
- [EDIT:] Hmm, A_Classes.JSON.Load(vText) and/or Class("JSON").Load(vText) versus JSON.Load(vText) would have been more intuitive, and safer, and you can see it's class. And you wouldn't need #Warn ClassOverwrite.