keys with numeric names

[jeeswg]

- I found that in AHK v2, the assignment of values to keys in arrays is different.
- In AHK v1 this creates 2 keys, in AHK v2 this creates 1 key.

Code: Select all

obj := {}
obj[1] := "a"
obj["1"] := "b"

- Overall, with the various for/against arguments considered, I think this behaviour is probably better. However, is there a way to actually assign keys with a name that looks like an integer, but where that name is stored as a string.
- Although there may be workarounds (e.g. prefixing keys with a character for when you want to sort numbers/strings as strings), if there is not *some* way to do this, this would be a fundamental reduction in the general power of AutoHotkey objects.
- I know that for example when dealing with Explorer objects, sometimes you want to refer to item 123 (the 124th item), and sometimes you want to refer to a folder called '123'. So there may be important scenarios in AutoHotkey, where at least having a way to do this would be beneficial.

Code: Select all

q::
oArray := Object(1, "a", "1", "b")
vOutput := ""
for vKey, vValue in oArray
	vOutput .= vKey " " vValue "`r`n"
MsgBox(vOutput)
;MsgBox, % vOutput
return

;AHK v1
;1 a
;1 b

;AHK v2
;1 b

Some comments on the matter:
detect/Remove duplicate values in array - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 13#p181713

Some relevant information from the documentation:
Objects
https://autohotkey.com/docs/Objects.htm

•Integer keys are stored using the native signed integer type. AutoHotkey 32-bit supports integer keys in the range -2147483648 to 2147483647. AutoHotkey supports 64-bit integers, but only AutoHotkey 64-bit supports the full range as keys in an object.

Objects
https://lexikos.github.io/v2/docs/Objects.htm

•Integer keys are stored using the native signed integer type where possible. Integers which are less than -2147483648 or greater than 2147483647 are stored as strings on AutoHotkey 32-bit but as integers on AutoHotkey 64-bit. (By contrast, 64-bit integers can be stored as values on either version.)

Thank you for reading.

[nnnik]

- Overall, with the various for/against arguments considered, I think this behaviour is probably better. However, is there a way to actually assign keys with a name that looks like an integer, but where that name is stored as a string.

Yes use 2 Objects. You should have probably done so even in v1.

- Although there may be workarounds (e.g. prefixing keys with a character for when you want to sort numbers/strings as strings), if there is not *some* way to do this, this would be a fundamental reduction in the general power of AutoHotkey objects.

You don't seem to understand a lot about objects yet you talk about their power level.

- I know that for example when dealing with Explorer objects, sometimes you want to refer to item 123 (the 124th item), and sometimes you want to refer to a folder called '123'. So there may be important scenarios in AutoHotkey, where at least having a way to do this would be beneficial.

And you do that by accessing a key and there is no other way you could imagine doing this?

BTW AutoHotkey treats the string "123" and the number 123 exactly the same on every occasion because towards AutoHotkey they are the exact same thing.
I think it would be unwise to add an exception to that rule.

[Helgef]

is there a way to actually assign keys with a name that looks like an integer, but where that name is stored as a string [?]

To me, this looks like integers,

Code: Select all

obj[0x0] := 0
obj["0x0"] := 1

If a string key can be converted to an integer (of the native signed integer type) and back to a string without loss of data, it is stored as an integer.

Hence, if it cannot, it isn't.

---

AutoHotkey treats the string "123" and the number 123 exactly the same on every occasion

It is not true, see any of jeeswg's examples above.

Cheers.

[jeeswg]

You should have probably done so even in v1.

- Why 'should'? It worked fine in AHK v1, there's nothing wrong with storing both string keys and numeric keys in the same array.

You don't seem to understand a lot about objects

- Evidence?

yet you talk about their power level.

- I don't know if you perceive 'power level' to have some special meaning.
- What I was saying was that in AHK v1 it was very straightforward: you had string keys and numeric keys, you could have any string key name you wanted, simple and powerful. In AHK v2, you cannot have certain string key names, if the string looks like an integer, AFAIK.
- I'm asking if there's still a way to create string keys with any name you want, if not, then part of the simplicity and generality of arrays is lost.

And you do that by accessing a key and there is no other way you could imagine doing this?

- Apologies, but sometimes I find your posts difficult to understand, even when I translate from the German forum cf. other translated posts.
- I did mention workarounds above, but the point of this thread is to ask about the raw possibilities of arrays, which appear to be being reduced in AHK v2, unless a subsidiary method/function is available.

[nnnik]

You should have probably done so even in v1.

- Why 'should'? It worked fine in AHK v1, there's nothing wrong with storing both string keys and numeric keys in the same array.

You don't seem to understand a lot about objects

- Evidence?

This post and your entire statements in it are evidence of that. An Array (you need to understand that first ) is a data type meant for storing data with one way to access it. Your difference between number and strings are 2 ways to access something therefore you should either use 2 arrays or use an object from the start.

- What I was saying was that in AHK v1 it was very straightforward: you had string keys and numeric keys, you could have any string key name you wanted, simple and powerful. In AHK v2, you cannot have certain string key names, if the string looks like an integer, AFAIK.

You can though? You just cannot store integer keys and string keys that may end up looking like integers in the same array with different values.

- I'm asking if there's still a way to create string keys with any name you want, if not, then part of the simplicity and generality of arrays is lost.

I think the opposite is the case since it is now consistent with the majority of cases.

And you do that by accessing a key and there is no other way you could imagine doing this?

- Apologies, but sometimes I find your posts difficult to understand, even when I translate from the German forum cf. other translated posts.
- I did mention workarounds above, but the point of this thread is to ask about the raw possibilities of arrays, which appear to be being reduced in AHK v2, unless a subsidiary method/function is available.

What I meant here is that you use arrays in the wrong way. You should use a folder object instead of an array in these occasions - what you basically did was abusing an array in a hackish way. Now with this update you pay the price for using a hackish method - your method is simply no longer available.

[guest3456]

some of this is already documented:
https://autohotkey.com/v2/v2-changes.htm

[jeeswg]

- In JSON, is it possible to have 1 (numeric name) and "1" (string name) keys?
JSON - Wikipedia
https://en.wikipedia.org/wiki/JSON
- If it is possible, that could prove a problem, if there wasn't *a* way to read/write the "1" etc keys.

- One thing you can do at present, in AHK v2, is to use a Scripting.Dictionary object.

Code: Select all

q:: ;create numeric + string keys
oArray := ComObjCreate("Scripting.Dictionary")
oArray.Item(1) := "numeric"
oArray.Item("1") := "string"
MsgBox(oArray.Item(1) "`r`n" oArray.Item("1"))
return

[lexikos]

No. JSON requires keys to be quoted strings.

JavaScript allows the quote marks to be omitted, but it is still a string.

Code: Select all

for (x in {0:1}) alert(typeof(x)); // Shows "string"
alert(({0:1})["0"]); // Shows "1"