Global variables unusable in AHK 2.0.2

[madsounds]

Dear AHK devs, please fix this crazy global variables behavior, which becomes hell every moment I'm trying to rewrite AHK-2-alpha's scripts into AHK 2.0 (specifically 2.0.2). How you end up with such implementation?

I mean, why now I have to update information that "yes, this var is global, for sure it's global" if I ALREADY choose that in the global scope? Half of my variable are global — and now, with this AHK 2.0 implementation, I have to creep through every function and make a list of global variable that this function uses.

And if before I could write this...

Code: Select all

;Script for AutoHotkey 2 — some alpha build.
global var1 := "value one"
global var2 := "value two"
global var3 := "value three"

function f_a()
{
	var1 := "some text one"
	MsgBox var1
}

function f_b()
{
	var2 := "some text two"
	MsgBox var2
}

function f_c()
{
	var 3 := "some text three"
	MsgBox var3
}

...instead, now I have to remind the every single global variable that it's actually global!

Code: Select all

;Script for AutoHotkey 2.0.2.
global var1 := "value one"
global var2 := "value two"
global var3 := "value three"

function f_a()
{
	global var1 ;This strange construction switches us from local var1 to the global one.
	var1 := "some text one"
	MsgBox var1
}

function f_b()
{
	global var2
	var2 := "some text two"
	MsgBox var2
}

function f_c()
{
	global var3
	var 3 := "some text three"
	MsgBox var3
}

And right now my scripts contain many of them, like up to 20 in a script, and how you imagine I have to crawl through every single variable of every single function, make a list of those that are global, filter duplicates and paste the list at the beginning of function, and when making any change to the function then repeat it all?

Any variable reference in an assume-local function may resolve to a global variable if it is only read. However, if a variable is used in an assignment or with the reference operator (&), it is automatically local by default. This allows functions to read global variables or call global or built-in functions without declaring them inside the function, while protecting the script from unintended side-effects when the name of a local variable being assigned coincides with a global variable.

Yes, also it allows my head to be aching every time I'm trying to use global variables inside a function. I've NEVER had any problem with remembering which of my variable are global, so I didn't accidently set a global var instead of local one, and I don't need to make myself a dozen of global var1 reminders in the beginning at every single fracking function that this variable is actually global. Instead, I always use local var1 := "value" construction which is standard for most of programming languages. When rewriting already written function, it becomes even harder to track what variables of script are global or not. By this implementation, you're throwing it back into AHK 1 era, which has simplified as hell for just some housekeeper users could write their shitty two-lines copy-paste script as fast as possible, while more advanced users were suffering of unusable syntax.

Anyway, what was wrong with the previous implementation? Which was like "if variable already mentioned as global, use the global one; if not, create the local one" or something.

UPD: I guess adding a directive for switching to the previous mode of treating global variable would be very acceptable.

[boiler]

Just to clarify some of the terminology, what you are asking for is something that was removed in v2 relative to v1, which is the super-global variable. In v2, as was the case in v1, the space outside of any functions is considered global space. When using the global keyword outside of a function in v1, it is defining variables as super-global, which means they are visible to all functions in addition to the global space. Yes, is has been specifically stated by lexikos that the global space does not include functions -- it can be thought of as international waters, and does not include the countries (functions) of the world. In v2, declaring a variable as global outside of a function does actually nothing other than act as an indicator/reminder to the programmer that a variable exists in the global space (i.e., outside of functions).

[the_alchemist]

I agree. Assuming that a variable is global only if you're reading from it, but not if you're writing to it makes no sense. If a variable was declared in the global scope, it's a global variable, identified by its name. That's what variable names are for.

[boiler]

Assuming that a variable is global only if you're reading from it, but not if you're writing to it makes no sense.

It does make sense because if you’re only reading from it, it can safely assume that you are referring to a global variable because it has otherwise never been assigned a value. So what else could the contents of that undefined variable be if not from a global variable?

[the_alchemist]

It does make sense because if you’re only reading from it, it can safely assume that you are referring to a global variable because it has otherwise never been assigned a value. So what else could the contents of that undefined variable be if not from a global variable?

But if you're writing to a variable that has been declared in global space, why would you assume it's local?

[boiler]

But if you're writing to a variable that has been declared in global space, why would you assume it's local?

Because functions aren't always written in the context of knowing what the global variables are. In fact, it's a best practice that they shouldn't have to. It's one of the tenets of object-oriented programming. If you use a function someone else has written, as is often the case with those that are shared on the forum that are meant to be used as library functions as an example, the author of the function should not have to concern himself/herself with potentially clobbering a global variable without having to explicitly declare it as local. Imagine if your library functions all had potential conflicts with your script's global variables. They should be able to assume that its scope is local unless they explicitly change that. In the case of v2, they could change that by declaring a variable as global or by referencing a variable without ever assigning it a value.

[FanaticGuru]

Autohotkey has gone from a fairly limited scripting language to a fairly robust scripting language. With all the good and bad that goes along with that depending on what you want. AHK v2 requires more thought about scope. In general, that makes simple scripts harder and complex scripts easier.

10 to 100 lines of code, scope doesn't matter much. You can keep all the code straight in your head pretty easy. 1,000 to 10,000 lines of code, scope starts to become pretty important because at that point all the code was probably not written by the same person and if by one person then probably over a considerable amount of time.

I assume the trend is to make Autohotkey more capable, not less. That almost mandates more complicated. One of the keys to more capable overall, is vast libraries of code so that each user can leverage the work of other users. One user can only do so much alone. Vast libraries of code that can be used together easily, require stricter control of scope.

I would consider trying to reduce your dependence on super global variables. The world doesn't like super global variables. And while most people are not smart, all the people are pretty smart. So, I would assume there is a reason.

If you don't care anything about scope, you can just put global at the first of every function.

Nested functions can also help some with scope. Related functions that work together can be nested or made into a class that have their own rules about scope.

If you really like super global then user defined objects are close to super global.

Code: Select all

S := {} ; super global object
S.Fruit := 'Orange'
Report	
Apple 
Report	
Pear
Report
S.Tree := 'Oak'
MsgBox S.Fruit '`t' S.Tree

Apple()
{
	S.Fruit := 'Apple'
	S.Tree := 'Pine'
}
Pear()
{
	S.Fruit := 'Pear'
}
Report()
{
	MsgBox S.Fruit '`t' (S.HasProp('Tree') ? S.Tree : '')
}

At least then it is easy to tell which of your 'variables' are super global because they have a S. prefix. It is not true super global as objects have their own special scope rules but it is superish.

On a different but related rant, I miss having libraries that just automatically load and add functions to AHK seamlessly like they were native which was nice for my own personal used. It was like I was using a custom version of AHK where I often forgot what was from my library and what was native. For just me, it did not matter but it was problematic when I shared scripts to always send the required library dependencies. I often forgot little functions that were from my library that I had been using for years. So, I understand the change but still hate putting a bunch of #include at the first when I am just tinkering around testing some code. It is like C++ or other languages where every piece of code starts out with a bunch of #include at the first.

FG