AutoHotkey Community

I don'nt like classes to be super-global by default. So what about:

I would modify this to: have the new keyword access the global scope. Then classes wouldn't have to be super-global.
I'm not sure what you mean by this. You could declare the class variable global if need be.

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

If the new operator has different behaviour to every other expression with that class name, it introduces inconsistency and makes it difficult to get through the concept that a class name is just a global variable. So when I originally thought of resolving the class name at load time (i.e. in order to avoid the need for a global declaration), I decided it was better to require the declaration (and to allow changes to the class variables to take effect).

Well, I do, and those users that have posted in Ask for Help when they were unable to get classes working surely would as well.
I plan to add an optional warning for re-assigning class variables, enabled by default.

Do you have some information that I don't?

From the confused users I've seen in Ask for Help, it seems to me that AutoHotkey's unconventional variable scoping rules are not intuitive even to beginners. Users with experience in other languages should expect "global" variables to actually be global, as is logical and conventional, not require redeclaration in each scope. So I think super-globals will be very welcome, though apparently a love-hate sort of feature if you're right.

I believe the reasoning behind AutoHotkey's variable scoping is:

• Variable declarations aren't required.
• Global variables are often used (without declaration) in global subroutines, especially hotkeys.
• Variables used in subroutines are often logically (but not actually) local to that subroutine, so shouldn't be automatically visible in functions.

The implication is that you should probably be using local variables; but with the current design, it is often inconvenient. On that note, block-scoped variables would be a better solution to the problem (pseudo-code follows):

So why must a variable in "global scope" (i.e. autoexecute-section) be declared as "super-global" using the "keyword" global, when classes don't have to? (I remember "Common source of confusion" in prior help files).

See previous post: "I believe the reasoning ..."

See previous post:

I don't.

just me:

While classes technically just act like global variables, in practice they are used like functions. One always has access to all functions by name, regardless of scope. Therefore, classes are super-global by default.

Also, as Lexikos has mentioned, variables in subroutines are technically in the global scope, but in practice they are ofttimes treated as local variables. One would not want all of those local-like global variables messing up functions' supposedly local variables unless explicitly stated as such. Therefore, global-space variables are not super-global by default.

Edit: @Tuncay: oh yeah, I forgot to mention, local variables per block sounds like a really cool idea.

_________________
Scripts - License

That reminds a wish from me from 2007! >>> Local variables inside blocks (e.g. loop)
Would still like to see it implemented.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--