Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AutoHotkey_L v1.1.05 beta: faster RegEx and more


  • Please log in to reply
37 replies to this topic
just me
  • Members
  • 1496 posts
  • Last active: Nov 03 2015 04:32 PM
  • Joined: 28 May 2011
I don'nt like classes to be super-global by default. So what about:
Class Dummy { ; not super-global
}

Class Static Dummy { ; not super-global and cannot be overwritten
}

Global Class Dummy { ; super-global
}

Global Class Static Dummy{ ; super-global and cannot be overwritten
}


jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

How about making class variables visible only to the new operator?

I would modify this to: have the new keyword access the global scope. Then classes wouldn't have to be super-global.

They would still have to exist as global variables though so you can access their static properties.

I'm not sure what you mean by this. You could declare the class variable global if need be.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

How about making class variables visible only to the new operator?

I would modify this to: have the new keyword access the global scope. Then classes wouldn't have to be super-global.

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).

I don'nt like classes to be super-global by default.

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.

Class Static Dummy { ; not super-global and cannot be overwritten
}

I plan to add an optional warning for re-assigning class variables, enabled by default.

I can see coming that many users will be against super globals.

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:
[*:21h23xyv]Variable declarations aren't required.
[*:21h23xyv]Global variables are often used (without declaration) in global subroutines, especially hotkeys.
[*:21h23xyv]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):
^+o:: ; Open folder of file in editor.
{
    [color=red]local title, path[/color]
    WinGetTitle title, A
    RegExMatch(title, ".*?(?=\\[^\\]+ [-*] SciTE)", path)
    Run %path%
}


just me
  • Members
  • 1496 posts
  • Last active: Nov 03 2015 04:32 PM
  • Joined: 28 May 2011

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 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).

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
See previous post: "I believe the reasoning ..."

just me
  • Members
  • 1496 posts
  • Last active: Nov 03 2015 04:32 PM
  • Joined: 28 May 2011
See previous post:

I don't.

infogulch
  • Moderators
  • 717 posts
  • Last active: Jul 31 2014 08:27 PM
  • Joined: 27 Mar 2008
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.

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
That reminds a wish from me from 2007! >>> Local variables inside blocks (e.g. loop)
Would still like to see it implemented.

No signature.