[?] is there a preferred way of dynamically creating a new variable now, after the most recent v2 update?

[SandyClams]

just wondering if there's something I missed. I'll sometimes loop over object properties or a list of strings and dynamically create local variables just for the convenience of not manually assigning them all, it's lazy but also pretty handy, would be sad to lose it.

[swagfag]

no, u havent missed anything. there straight up isnt a way of dynamically creating new variables now

Current versions of the language do not permit creating new variables dynamically. This is partly to encourage best practices, and partly to avoid inconsistency between dynamic and non-dynamic variable references in functions.

[lexikos]

N.B.

Variables cannot be created dynamically, but a variable can be assigned dynamically if it has been declared or referenced non-dynamically somewhere in the script.
Source: Variables and Expressions - Definition & Usage | AutoHotkey v2

Being unable to create a variable with a dynamic reference means that you must create it some other way, such as by simply including a non-dynamic reference to it somewhere in the script. If the change is preventing you from creating a variable dynamically, that means you were only ever accessing it dynamically. In that case, why weren't you using an array/object (directly)?


From v1,

Common source of confusion: Any non-dynamic reference to a variable creates that variable the moment the script launches. For example, when used outside a function, MsgBox %Array1% creates Array1 as a global the moment the script launches. Conversely, when used inside a function MsgBox %Array1% creates Array1 as one of the function's locals the moment the script launches (unless assume-global is in effect), even if Array and Array0 are declared global.

In v1, the actual source of the confusion was inconsistency between dynamic references, pseudo-arrays and non-dynamic references. I think the main issue wasn't the above, but the special case of pseudo-arrays:

For commands that create pseudo-arrays (such as StringSplit), each variable in the resulting pseudo-array is local if the assume-global mode is not in effect or if the pseudo-array's first element has been declared as a local variable

Users declare the first element as local/global so that they get a local/global pseudo-array, but then are unable to reference it non-dynamically because the individual elements are not declared. Or one might read or assign a global variable dynamically without declaration, but fail to do so non-dynamically. These issues were eliminated in v2.0-a002 by making dynamic references and commands which create pseudo-arrays consistent with non-dynamic references.

The "common source of confusion" was then (or at some point) removed from the documentation because it wasn't a common source of confusion anymore. It is not very clearly documented anywhere else, but there are hints:

Because the words local, global, and static are processed immediately when the script launches, [...]
A dynamic declaration such as global Array%i% is not possible, since all non-dynamic references to variables such as Array1 or Array99 would have already been resolved to addresses.
Source: Functions - Definition & Usage | AutoHotkey v2

Each script is semi-compiled while it is being loaded and syntax-checked. [...]
Each reference to a variable or function is resolved to a memory address, unless it is dynamic.
Source: Script Performance | AutoHotkey v2

Note that although you may still initialize your variables using a loop and dynamic references, if you only ever assign them dynamically and do not declare them local, they may end up being global.

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.
Source: Functions - Definition & Usage | AutoHotkey v2

[swagfag]

N.B.

Variables cannot be created dynamically, but a variable can be assigned dynamically if it has been declared or referenced non-dynamically somewhere in the script.
Source: Variables and Expressions - Definition & Usage | AutoHotkey v2

Being unable to create a variable with a dynamic reference means that you must create it some other way, such as by simply including a non-dynamic reference to it somewhere in the script. If the change is preventing you from creating a variable dynamically, that means you were only ever accessing it dynamically. In that case, why weren't you using an array/object (directly)?

thats a very astute observation, as always

---

the object property use case i kind of almost get, if you:

• dont care about the fact that ull be working(most likely) with copies of the properties, so any future assigning to them wont necessarily reflect on the original object they were copied from
• do care about the fact that ull be working(most likely) with copies of the properties, so changing them wont necessarily reflect on the original object they were copied from
• u dont want to incur whatever performance penalty there is for accessing the properties
• u dont want objectInstance. littered throughout wherever ure accessing the properties(this could have been prevented if ahk had something like https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with#using_with or https://docs.microsoft.com/en-us/office/vba/language/reference/user-interface-help/with-statement)

the list of strings case i dont get at all. maybe u can show an example?

[SandyClams]

@swagfag, it's the same general thing when I do it with strings. Sometimes I just find a use case where I can spare myself some manual typing or some perceived clutter by streamlining the creation of a few variables. Or I just want to be "clever"

Code: Select all

; for each given method name,
for (methodName in ['GetOwnPropDesc', 'DefineProp']) {
  ; set borrowed method from object prototype to local function variable
  %methodName% := Object.Prototype.%methodName%
}

@lexikos, it's not that I'm actually inhibited from the creation of the variable. I do later use the variable normally and so it still works. I just notice things have been switched up, also I'm triggering VarUnset warnings which is problematic, so I was hoping to find if there was some other, better practice as I do it

[kczx3]

@SandyClams
It seems you're really looking for object destructuring from JS or extract/list from PHP, right?

[SandyClams]

^^ haha, yep. Pretty much exactly that, or whatever the laziest and most feasible facsimile is

[drozdman]

Variable assignment notations ":=" and "=" were very useful for creating variables dynamically. The quickness of it was the beauty of AHK. Though, the change is understandable.
Still...
Why is the notation ":=" maintained if there is no need for distinguishing it from literal assignments?
It would be sensible to use "=" only. Or add "=" and retain ":=" for compatibility issues.
That's what creates confusion in AHK when one switches to it from other programing languages. Existence of ":=" and "=" were not confusing to me at all from the beginning, btw (as it was suggested somewhere).
Necessity to write ":=" instead of "=" slows down the writing process.

[boiler]

Why is the notation ":=" maintained if there is no need for distinguishing it from literal assignments?
It would be sensible to use "=" only. Or add "=" and retain ":=" for compatibility issues.
That's what creates confusion in AHK when one switches to it from other programing languages. Existence of ":=" and "=" were not confusing to me at all from the beginning, btw (as it was suggested somewhere).
Necessity to write ":=" instead of "=" slows down the writing process.

This was discussed a couple of years ago here (among other times like this much older thread referenced by lexikos), and it’s not up for consideration, as you’ll see in the previous discussion.