Overwritte Class Variables | ExitApp, __Delete & Static Variables

Discuss the future of the AutoHotkey language
lexikos
Posts: 6445
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables

14 May 2019, 20:43

I will probably do this, or make #Warn ClassOverwrite the default, or make it mandatory behaviour, to be reimplemented later as constants.
I wrote:I might consider making class names read-only identifiers (not variable) in v2. It would not reduce flexibility much since one can still clone the class and modify the original object as needed. However, the current framework has no provision for constants, [...]. Also, consider the fact that nested classes are (in current versions of the language) simply assigned to array elements, and a constant array element doesn't make much sense.
Objects may have the provision for read-only value properties, which will make it easy for nested classes.
User avatar
nnnik
Posts: 4223
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables

15 May 2019, 04:12

#Warn ClassOverwrite warns you every time a class is overwritten. This includes subclasses.
Overwriting a subclass unintentionally is rather difficult - yet the #Warn Mode would warn the user.
On the other hand - Overwriting a super global variable is rather easy. Immutability modifiers are far off for classes too.

I think what you suggest should rather result in a #Warn Mode global - that warns the user every time a super global or global variable is written to, inside a function without that function being assume global or the variable explicitly being defined as global.
Recommends AHK Studio
lexikos
Posts: 6445
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables

15 May 2019, 22:00

Firstly, subclasses are not nested classes. Subclasses and superclasses are equally affected by the problem, as either can be super global.

Secondly, #Warn does not warn about nested classes. It can only detect writes to super global variables.

Finally, being able to use global variables without requiring a declaration in each function is exactly the point of a super global. Requiring a declaration inside the function to bypass your hypothetical warning when the variable is accessed (even if it is being assigned a value) would defeat the point of having or using super globals in the first place.

Classes are a special case where an assignment is more likely to be intended for a local variable.

> "Immutability modifiers are far off for classes too."

How would you know?
User avatar
nnnik
Posts: 4223
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables

16 May 2019, 04:17

Secondly, #Warn does not warn about nested classes. It can only detect writes to super global variables.
Thats good news. And means that most of my scripts wont be affected.
Finally, being able to use global variables without requiring a declaration in each function is exactly the point of a super global. Requiring a declaration inside the function to bypass your hypothetical warning when the variable is accessed (even if it is being assigned a value) would defeat the point of having or using super globals in the first place.

Classes are a special case where an assignment is more likely to be intended for a local variable.
So could it be made possible to supress the warning by making the class a super global variable?
Unless there is a way to supress the warning in case the behaviour warned about it doesnt make sense to display it by default.
> "Immutability modifiers are far off for classes too."

How would you know?
I estimated that based on the developments in the last few months.
The last few weeks were very good procution wise - I'll glady be wrong with that estimation.
Recommends AHK Studio
lexikos
Posts: 6445
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables

17 May 2019, 18:51

So could it be made possible to supress the warning by making the class a super global variable?
No.
  • You can't make it what it already is.
  • global class Foo {} makes little sense when Foo is (super) global by default.
  • Declaring a separate global Foo, or even declaring global class Foo, does not adequately express the intent that you be able to overwrite the class. Global only specifies scope. Consider this scenario: In one part of the script you declare and use a global Foo, unknowingly overwriting a class defined in another part of the script.
  • If it becomes a load-time constant instead of a variable, assigning to it will always be an error.
As per the documentation, Warnings are not shown for nested classes or dynamic variable references. This is one way to bypass the warning.

If someone wants an identifier to refer to a class but allow reassignment, they should define a separate class and variable, and perform an assignment.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 3 guests