keys with numeric names

Discuss the future of the AutoHotkey language
User avatar
jeeswg
Posts: 2982
Joined: 19 Dec 2016, 01:58
Location: UK

keys with numeric names

18 Nov 2017, 16:00

- 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] [Download] GeSHi © Codebox Plus

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] [Expand] [Download] GeSHi © Codebox Plus



Some comments on the matter:
detect/Remove duplicate values in array - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=39697&p=181713#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.
User avatar
nnnik
Posts: 2314
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: keys with numeric names

19 Nov 2017, 02:54

jeeswg wrote:- 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.
jeeswg wrote:- 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.
jeeswg wrote:- 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.
Recommends AHK Studio
Helgef
Posts: 2476
Joined: 17 Jul 2016, 01:02
Contact:

Re: keys with numeric names

19 Nov 2017, 18:41

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] [Download] GeSHi © Codebox Plus

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.
User avatar
jeeswg
Posts: 2982
Joined: 19 Dec 2016, 01:58
Location: UK

Re: keys with numeric names

19 Nov 2017, 23:05

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.
User avatar
nnnik
Posts: 2314
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: keys with numeric names

20 Nov 2017, 01:54

jeeswg wrote:
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.
Recommends AHK Studio
guest3456
Posts: 2076
Joined: 09 Oct 2013, 10:31

Re: keys with numeric names

20 Nov 2017, 10:16

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


Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 1 guest