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

Get help for the alpha version of AutoHotkey v2 here. Please state the v2 version you are working with in the title when making a new topic.
Helgef
Posts: 4031
Joined: 17 Jul 2016, 01:02
Contact:

Re: [a104] are builtin classes protected against accidental overwriting?

04 Oct 2019, 13:07

jeeswg wrote: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 :arrow: is.
is wrote:If Type is an object, the result is true if Value is an object derived from Type, directly or indirectly.
User avatar
jeeswg
Posts: 6904
Joined: 19 Dec 2016, 01:58
Location: UK

Re: [a104] are builtin classes protected against accidental overwriting?

04 Oct 2019, 13:52

- @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? ;)
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Helgef
Posts: 4031
Joined: 17 Jul 2016, 01:02
Contact:

Re: [a104] are builtin classes protected against accidental overwriting?

05 Oct 2019, 04:08

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.
User avatar
jeeswg
Posts: 6904
Joined: 19 Dec 2016, 01:58
Location: UK

Re: [a104] are builtin classes protected against accidental overwriting?

05 Oct 2019, 04:58

- 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.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA

Return to “AutoHotkey v2 Help”

Who is online

Users browsing this forum: No registered users and 16 guests