AutoHotkey Community

1.1.00.01 (July 17)

Fixed: Modifier keys weren't auto-released when sending special chars. /
Fixed: Scancode/modifier-key mapping conflicts such as sc1xx vs ^sc0xx.
Fixed: $ and #UseHook had no effect if used only on the second or subsequent instance(s) of a hotkey.
Fixed: Potential crash when returning a value from a __Delete meta-function.
Fixed: "Uninitialized variable" warnings were triggered by the debugger.

Changed: base.Method() no longer triggers a default meta-function or a warning.
Changed: Gui +(Ex)Style no longer hides/shows the Gui.
Changed the debugger to report type="undefined" for uninitialized variables.

Added check to avoid incorrectly sending keystrokes for characters which actually require the "hankoku" key.
Added support for integers as class variable names.
Added "Static" keyword for declaring class variables. (See below)

Downloads (etc.)

Use of the var keyword in class definitions to declare static class variables should be avoided, as a future version (probably the next release) will repurpose it for declaring instance variables. There are some cases where behaviour won't be adversely affected; in other cases, scripts should be updated to use the static keyword.

Very nice! I look forward very much to instance variables.

It's also good to see that the hide/show quirk was fixed. Were the issues that Chris described in the source an artifact from older windows versions or did you discover a better way to avoid them?

Thanks for the release


Interesting - would there be any way to access this instance variable via a method defined in the class - other than accessing the class object by name? (see here)

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

I assume that the instance variable would be a simple key in the object that gets created by using the new operator, much like defining the variable in its constructor.

Thanks for this release!

Awesome! Any chance the applicable changes are merged into ahk v2 alpha?



Hmm, along these lines, why don't you just take out "var" as a keyword completely, and use "local" for declaring instance variables along with what you're planning already with "static" as declaring class variables?

No need to add unnecessary keywords. KISS

_________________
Scripts - License

I'm not sure if this was discussed before (I think I vaguely remember), but is var needed at all?

Right. However, it will necessarily be separate from __New so that the initializers can be executed in order of base class -> derived class, and before __New is called.
It was a couple days ago, according to the list of changes in the v2 thread...
Local variables are scoped to a function. Instance variables are not. A keyword like "set" or "init" might be more accurate (and less misleading), but not as nice. All instance and class "variables" still need to be qualified with the object (e.g. this.var), so differentiating them from local variables might be important.
In v1.1.00.01 it's the same as "static", but kept so that existing scripts don't need to be changed (yet). Instance variables (which aren't implemented yet) are needed in some cases, particularly those involving objects - e.g. static arr := [1,2,3] creates a shared object whereas var arr := [1,2,3] creates one for each instance of the class.

Why use keyword at all? I can understand that static variables need to be distinguished from instance variables, so that should have a keyword. I don't however understand why this can't work.

_________________
aboutscript ⍟ apps ⍟ scripts
Any code ⇈ above ⇈ requires AutoHotkey_L to run

Symmetry/consistency.

i agree. this is all getting confusing for me, but i guess we'll see what the final thing looks like in the next release, and then maybe it'll make more sense

Why not add public/private keywords then? Then you could get rid of the "var" keyword and still provide functionality with the keyword

+1

Keywords are nice for readability, but "var" is one of the most common names for all generic variables and doesn't convey any special meaning. Keywords should be descriptive. On the other hand, memorizing keywords is another barrier to entry that makes it harder for new users to learn a language. Every keyword should produce a tangible benefit, i.e. provide some utility that cannot easily be gained in another way. On that note, I suggest an eventual page in the Help file dedicated to keywords (with a table similar to the one dedicated to escape characters).

Access modifiers are irrelevant. Anything with a reference to the class/object can access the "variable", and anything without a reference cannot. Access controls could not be implemented at load-time without typed variables, and could not be implemented at run-time without reducing performance (and providing very little benefit for that matter).

I've decided to remove the "var" keyword entirely in the next release. Instance variables will be declared/initialized by simply writing Name := Expression in the class definition, outside any method definitions. However, note that Name is the only context in which you will be able to refer to an instance variable without specifying the object (like this.Name). Expression can refer to this, but any other variable reference will be global.

Thanks for the feedback.