Objects may have the provision for read-only value properties, which will make it easy for nested classes.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.
Overwritte Class Variables | ExitApp, __Delete & Static Variables
Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables
I will probably do this, or make #Warn ClassOverwrite the default, or make it mandatory behaviour, to be reimplemented later as constants.
Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables
#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.
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
Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables
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?
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?
Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables
Thats good news. And means that most of my scripts wont be affected.Secondly, #Warn does not warn about nested classes. It can only detect writes to super global variables.
So could it be made possible to supress the warning by making the class a super global variable?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.
Unless there is a way to supress the warning in case the behaviour warned about it doesnt make sense to display it by default.
I estimated that based on the developments in the last few months.> "Immutability modifiers are far off for classes too."
How would you know?
The last few weeks were very good procution wise - I'll glady be wrong with that estimation.
Recommends AHK Studio
Re: Overwritte Class Variables | ExitApp, __Delete & Static Variables
No.So could it be made possible to supress the warning by making the class a super global variable?
- 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.
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 Development”
Who is online
Users browsing this forum: No registered users and 18 guests