MapKeys() on empty map

[c.haslam]

I was surprised to find that, if a map has no elements, MapKeys() returns an array with no dimensions:

Local $map[]
Local $mapKeys = MapKeys($map)
MsgBox(0,'',UBound($mapKeys,0)&','&UBound($mapKeys,1))

shows 0,0

It would be more logical to me for MapKeys() to return a 1-d array with zero elements.

It would then work with

For $key in MapKeys($map)
...
Next

as does a map with elements.

Also, to my knowledge this is the only case where a 0-d array can exist in AutoIt. (Correct me if I am wrong.)

I also note that the value of @error is 1 for both the argument being an empty map, and for it being a variable or constant other than a map.

I do not see why MapKeys() returns @error=1 for a map with no elements, because to me getting the keys in a map with no elements is not necessarily an error.

Further, the Help says that on failure MapKeys() returns "a zero based array". As I see it, a 0-d array is not based.

Thoughts?

I do have a work-around:

Local $map[]
Local $mapKeys = cMapKeys($map)

Func cMapKeys($map)
    Local $mapKeys = MapKeys($map)
    If @error Then
        If IsMap($map) Then
            Local $mapKeys[0]
        Else
             MsgBox(0,'Error','Argument to cMapKeys() is a '&VarGetType($map))
            Exit
        EndIf
    EndIf
    Return $mapKeys
EndFunc

 

Edited March 19, 2018 by c.haslam

[Bilgus]

You Must be using the Beta?

[c.haslam]

Yes. 3.3.15.0

[jchd]

7 hours ago, c.haslam said:

Also, to my knowledge this is the only case where a 0-d array can exist in AutoIt. (Correct me if I am wrong.)

This isn't a 0D array (that could qualify a flat variable), but a different unicorn: it's a 1D array with zero row.

AutoIt allows array dimension(s) to be 0: Local $a[0] is perfectly valid, just like $a[0][3] (a 2D array of zero row of three columns each, or $a[0][2][5] (a 3D array of zero planes of 2 rows by 5 columns).

All of this is perfectly sensible, as functions returning an array should return a suitable dimensionned array with zero rows when there is no data to return. That would save extra code in applications and verbiage in help. Unfortunately this possibility is relatively recent and older UDFs do return anything like an empty string or an error in such case, which is plain wrong IMVHO.

If you're the only child and someone asks for the number of brothers/sisters you have, you say "zero" or "none" but you never reply "error" or "" (an empty string).

[iamtheky]

what if you are a string and someone asks about the boundaries of your dimensions?

$mapKeys = "this is a thing that is not an array"
MsgBox(0,'',UBound($mapKeys,0)&','&UBound($mapKeys,1))

I'm not saying zero is an incorrect response, but still debate worthy IM-even humbler-O.

Edited March 20, 2018 by iamtheky
wordiness

[c.haslam]

jchd,

I think that you are mistaking which is the dimension (number of subscripts) value, so below I have an example  using AutoIt $ constants:

#include <AutoItConstants.au3>

Local $ar2d[5][8]
MsgBox(0,'',UBound($ar2d,$UBOUND_DIMENSIONS)&':'&UBound($ar2d,$UBOUND_ROWS)&','&UBound($ar2d,$UBOUND_COLUMNS)); shows 2:5,8  so 5 rows and 8 columns

Local $ar1d[3]
MsgBox(0,'',UBound($ar1d,$UBOUND_DIMENSIONS)&':'&UBound($ar1d,$UBOUND_ROWS))    ; shows 1:3 so 3 rows

Local $map2[]
$map2.one = 1
$map2.two = 2
$map2.three = 3
$map2.four = 4
Local $keyAr = MapKeys($map2)
MsgBox(0,'',UBound($keyAr,$UBOUND_DIMENSIONS)&':'&UBound($keyAr,$UBOUND_ROWS))  ; shows 1:4 so 4 elements

Local $map1[]
$map1.one = 1
Local $keyAr = MapKeys($map1)
MsgBox(0,'',UBound($keyAr,$UBOUND_DIMENSIONS)&':'&UBound($keyAr,$UBOUND_ROWS))  ; shows 1:1 so 1 element


Local $map0[]
$keyAr = MapKeys($map0)
MsgBox(0,'',UBound($keyAr,$UBOUND_DIMENSIONS))  ; shows 0 so neither rows nor columns

I would expect the last example to be:

Local $map0[]
$keyAr = MapKeys($map0)
MsgBox(0,'',UBound($keyAr,$UBOUND_DIMENSIONS)&':'&UBound($keyAr,$UBOUND_ROWS))  ; should show 1:0 so 0 elements

 

[jchd]

I ain't mistaking anything: I never pretended that MapKeys was correct!

ConsoleWrite(@LF & "! Array returned by MapKeys" & @LF)
Local $map0[]
Local $keyAr = MapKeys($map0)
ConsoleWrite("MapKeys of empty Map = bug!  " & @TAB & VarGetType($keyAr) & @TAB & Ubound($keyAr, 0) & '-D : (' & Ubound($keyAr, 1) & ')' & @LF) ; demonstrates bug of MapKeys: array is ill-formed
ReDim $keyAr[3]
ConsoleWrite("ReDim [3] of above           " & @TAB & VarGetType($keyAr) & @TAB & Ubound($keyAr, 0) & '-D : (' & Ubound($keyAr, 1) & ')' & @LF) ; yet array can de ReDim-ed
$map0[17] = "Hello World!"
$keyAr = MapKeys($map0)
ConsoleWrite("MapKeys of non-empty Map     " & @TAB & VarGetType($keyAr) & @TAB & Ubound($keyAr, 0) & '-D : (' & Ubound($keyAr, 1) & ')' & @LF) ; nos bug here: array is correct

; this has to do mith MapKeys only
ConsoleWrite(@LF & "+ Declared and ReDim-ed arrays" & @LF)
Local $a[0]
ConsoleWrite("Local $a[0]                  " & @TAB & VarGetType($a) & @TAB & Ubound($a, 0) & '-D : (' & Ubound($a, 1) & ')' & @LF)
ReDim $a[3]
ConsoleWrite("ReDim $a[3]                  " & @TAB & VarGetType($a) & @TAB & Ubound($a, 0) & '-D : (' & Ubound($a, 1) & ')' & @LF)
ReDim $a[0][3]
ConsoleWrite("ReDim $a[0][3]               " & @TAB & VarGetType($a) & @TAB & Ubound($a, 0) & '-D : (' & Ubound($a, 1) & ', ' & Ubound($a, 2) & ')' & @LF)  ; no more bug
ReDim $a[2][3]
ConsoleWrite("ReDim $a[2][3]               " & @TAB & VarGetType($a) & @TAB & Ubound($a, 0) & '-D : (' & Ubound($a, 1) & ', ' & Ubound($a, 2) & ')' & @LF)
Local $a[2][3]
ConsoleWrite("Local $a[2][3]               " & @TAB & VarGetType($a) & @TAB & Ubound($a, 0) & '-D : (' & Ubound($a, 1) & ', ' & Ubound($a, 2) & ')' & @LF)
Local $a[0][2][0][3][1][5][0]
ConsoleWrite("Local $a[0][2][0][3][1][5][0]" & @TAB & VarGetType($a) & @TAB & Ubound($a, 0) & '-D : (' & Ubound($a, 1))
For $i = 2 To UBound($a, 0)
    ConsoleWrite(', ' & UBound($a, $i))
Next
ConsoleWrite(')' & @LF & @LF)

 

[c.haslam]

We now understand each other: there is a bug in MapKeys.

I did not find it in Trac, so should I create a ticket?

 

 

Edited March 20, 2018 by c.haslam

[Melba23]

c.haslam,

As it says in the Beta Help file for all the Map* functions:

Warning: This feature is experimental. It may not work, may contain bugs or may be changed or removed without notice.

DO NOT REPORT BUGS OR REQUEST NEW FEATURES FOR THIS FEATURE.

So please do not. And as I understand it the whole Map datatype is broken and so may be removed a t any time - so do not get too attached to it.

M23

[c.haslam]

M23,

OK, I won't create a ticket.

I don't see the warning in 3.3.15.0 Help. Perhaps you would tell me where I can find the warning. I looked in Function Reference > Map Management, in the page for each of the Map*() functions, and in Language Reference > Variables.

I am only using maps to report their values in my cDebug . I can easily remove this feature.

[Melba23]

c.haslam,

Sorry, I am running a pre-release v3.3.15.1 where the warning is in a large red-bordered box at the top of each Map* function page. I have just checked the v3.3.15.0 Help file and you are quite correct - it does not appear there, which I find quite strange as I was sure we had added it. Anyway, it will be in the next Beta release - and my comments above still stand.

M23

[c.haslam]

Thank you for the info. Does 3.3.15.1 fix the bug in MapKeys()?

[kylomas]

Since it has warnings about the "bug", probably not!

[jchd]

AFAIK there are deeper and more serious issues with the current implementation of Maps, e.g. vanishing entries and such.

I'd find it terribly unfortunate if Jon decided to drop Maps as they are a real improvement.

[c.haslam]

I agree with you 100%: they add much to AutoIt.

It must be very hard to determine why entries go missing.