@lexikos 1. HUGE LEAP FORWARD! Further improvement to get rid of AHK
quirks! The first update I liked pretty much everything about it.
On paper. I gotta convert my code base from
v127 to
v128+ and test out every aspect yet.
2. How many people asked for it! New
VarRef operator saves lots of space (6 symbols
ByRef_ to 1
&). It does help to memorize
OutVar positions in the parameters list for built-in functions and gives an additional level of error checking control over it.
3. Super-global classes removal forces better programming practices and makes 1 step closer to better namespace management of Python-like libraries modularity.
4. Less redundant stuff (no more
.new explicit method) to call constructors! No more
local directives madness (sometimes it added up to 20% to code size for small functions).
5. Finally function's call/function's referencing syntax is similar to other languages! Though I would like one day u make function's call right parenthesis
() mandatory and completely remove "command syntax". We've moved far away from
AHK v1 anyways - no need to cling to this any longer: according to polls the majority is for command syntax removal.
6. Merged methods and properties namespace is now similar to other languages. Also now it lets check a class's methods and properties in one pass as properties.
7. Also I noticed the documentation was greatly revamped with adding side-effects, known limitations and additional examples. Quality leap forward! Though the differences between the latest version and
AHK v1, previous
AHK v2 versions might require additional examples still. U might even want to create the whole "how to convert older scripts to
AHK 2 v129" section.
Some issues and suggestions so far:
1.Fat arrow functions in global scope are no longer assume-global. Due to the new rules, they can read global variables and create local variables, but not assign global variables.
At first I was super agitated to learn about
v128+ on paper. But it turns out
fat-arrow functions at the global scope r not
assume-local (yet):
Code: Select all
global v:=1
f()=>v:=8 ;looks like it assigns to a global var still.
msgbox(A_AhkVersion) ;2.0 a129
msgbox("v: " v) ;1
f()
msgbox("v: " v) ;8
2. Within an assume-local function, if a given name is not used in a declaration or as the target of a non-dynamic assignment or the reference (&) operator, it may resolve to an existing global variable.
Its not clear for me what do u mean by saying that reference
& operator changing the way how AHK resolves
global variables. Could u provide an example? Is it exactly the following side-effect (uncomment 1 line to make
log local by assessing it with
isset(&log):
Code: Select all
class log{
}
class ini{
static load(){
msgbox("inside class: isset(log): " isset(&log)) ;FALSE. really? isn't it declared as class (=initialized global var)?
}
}
msgbox("outside: isset(log): " isset(&log)) ;TRUE. ok
ini.load()
class json{
static dump(){
; msgbox("inside class 2: isset(log): " isset(&log)) ;uncomment this to make log local
msgbox(type(log)) ;class (ok) OR (if u uncomment the line above) "this var has not been assigned a value. specifically: local log (same as a global)"
}
}
json.dump()
But
how can I assess whether a class is declared outside or not w/o throwing errors and other side-effects of turning global to local resolution? before
v128 I used
isset(class_name) construction.
BTW, for debugging purpose it would be nice to have a special command to learn what AHK thinks of the current var within
the current namespace scope (attributes such as
global,
local,
static, simple nested function vs
closure or any other (in)valid status).
Stat(&var) or something like that that returns a string or an object describing its status (in details).
3. DllCall: The output value (if any) of numeric parameters with the * or P suffix is ignored if the script passes a plain variable containing a number. To receive the output value, pass a VarRef such as &myVar or an object with a Ptr property.
* or
P suffix remains for compatibility reasons but AHK doesn't let me use
"int", &var for
dllcall. It requires redundant
"intP" in this case still.
4. Each function definition creates a constant (read-only variable) within the current scope; therefore, scripts cannot assign to a variable with that name in the same scope.
This article in the documentation needs to be updated with heads up concerning methods. Methods (essentially, properties now) can be overwritten still thus
converting an existing code having the same method and property name in a class from
<128 versions flags no errors/warnings at load-time and may create unexpected results:
Code: Select all
class test{
static start()=>test.f:=0 ;no errors here
static F()=>msgbox("OK")
}
test.start()
test.f() ;yields an error at run-time thus leaving a sleeping hard-to-find error for rarely called functions.
I might further update on the matter in my
wishlist topic.