AutoIt v3.3.15.3 Beta & maps

[lorenz]

hi all,

I'm playing around with maps and mostly get them to do what I want 8-)

But there is one point where I'm not sure if what I want to do is supposed to work or not, or if I'm doing something wrong.

Local $map1[]
Local $map2[]

$map2.foo = 0
$map2.bar = $map1

$map2.bar.baz = "so far so good"

MsgBox(0, "", $map2.bar.baz & @CRLF & $map2.bar["baz"])

$map2.bar["baz"] = 0

the last line should be equivalent to the line just before the message box.
But after closing the box I get a runtime error

---------------------------
AutoIt Error
---------------------------
Line 11  (File "C:\Users\lenhardt\Desktop\AutoIt v3 Script (neu) (2).au3"):

$map2.bar["baz"] = 0
$map2.bar["baz"] ^ ERROR

Error: Variable must be of type "Object".
---------------------------

Originally I tried

$map2.bar[0] = 1

after that failed, I tried the other variants.

So, is this a bug, or not supposed to work?

 

Lorenz

[jchd]

You have a choice of syntaxes:

Local $map1[]
Local $map2[]

$map1["what gives?"] = 4
$map2.foo = 5
$map2.bar = $map1

$map2.bar.baz = "so far so good"

MsgBox(0, "", $map2.bar.baz & @CRLF & $map2.bar["baz"])

$map2.bar.baz = 3
$map2.bar.baz *= 3
$map2["bar"]["baz"] *= 10

$map2["bar"]["what gives?"] = -6

vd($map2)

vd() is a homebrew variable dump which yields:

Map[2]
      ['foo']                => Int32              5
      ['bar']                => Map[2]
            ['what gives?']        => Int32              -6
            ['baz']                => Int32              90

 

[lorenz]

Thanks.

But that confirms my suspicion that their is still a "feature" here 8-)

Because I don't think it's on purpose that $map2.bar["baz"] can be used to access the value of the entry, but not to assign a value to it.


Lorenz

[Melba23]

lorenz,

It does seem rather strange that only 1 of the 4 syntax options fails on assignment:

#AutoIt3Wrapper_Run_AU3Check=n

Local $map1[]
Local $map2[]

$map2.foo = 0
$map2.bar = $map1


$map2["bar"]["baz"] = "fred"

MsgBox(0, "", $map2.bar.baz & @CRLF & $map2.bar["baz"] & @CRLF & $map2["bar"].baz & @CRLF & $map2["bar"]["baz"])

$map2.bar.baz = "dick"

MsgBox(0, "", $map2.bar.baz & @CRLF & $map2.bar["baz"] & @CRLF & $map2["bar"].baz & @CRLF & $map2["bar"]["baz"])

$map2["bar"].baz = "dora"

MsgBox(0, "", $map2.bar.baz & @CRLF & $map2.bar["baz"] & @CRLF & $map2["bar"].baz & @CRLF & $map2["bar"]["baz"])

$map2.bar["baz"] = "oops"

MsgBox(0, "", $map2.bar.baz & @CRLF & $map2.bar["baz"] & @CRLF & $map2["bar"].baz & @CRLF & $map2["bar"]["baz"])

I will point Jon towards the thread.

M23

[lorenz]

Aaaaannnd the next "feature" 8-)

Global $mainMap[]

Global $childMap[]
$childMap[0] = "map0"

Global $childArray[] = ["array0"]


$mainMap.map   = $childMap
$mainMap.array = $childArray

MsgBox(0, "", $mainMap.map[0] & @CRLF & $mainMap.array[0])

$mainMap["map"][0]   = "works"

$mainMap["array"][0] = "not"
$mainMap.array[0]    = "neither"

sadly the solution for the sub-map problem does not work for a sub-array.

 

Lorenz

[lorenz]

Don't get me wrong. I'm not complaining, the maps feature is still beta, just pointing out the problems I stumble upon while probing around

 

Lorenz

[jchd]

That's one of the reason why I often recommend against nested arrays, maps or combinations thereof.

[jchd]

It looks like the square bracket syntax takes precedence over the dot syntax in the parser.

[Melba23]

jchd,

Quote

That's one of the reason why I often recommend against nested arrays, maps or combinations thereof.

I do it a lot - but I always extract the "inner" arrays/maps to a temporary variable before doing anything with them. And especially if I will be changing their content - after which I reassign them to their place in the "container".

M23

[jchd]

Yeah but it's clumsy. Often enough other data structures are more efficient and maintainable. Yet there are contexts where such structures are beneficial.

[lorenz]

20 hours ago, jchd said:

[...] Often enough other data structures are more efficient and maintainable. Yet there are contexts where such structures are beneficial.

That was my thought too when playing around with basic bar graphs. I needed a means to bundle all relevant informations pertaining a graph, so that handling multiple graphs got possible without much hassle ("playing" as in nothing serious, getting to know autoits GUI... functions).

in C, C++, Pascal or other such languages a struct (or class) would have been the prefered solution.
Having used gawk (with its associative arrays, aka maps), I knew maps to be an usable alternative.

I hope maps will mature over time, getting rid of the remaining flaws.

In the meantime I will try M23s workaround (reassigning subarrays/maps after changes)

Lorenz

Edited June 14, 2020 by lorenz

[jchd]

Alternatively you can use scripting.dictionary object(s), potentially nested, if you need .