Maps - don't allow empty keys or raise a Compiler warning

[Andre]

The main advantage (in my point of view) of maps is, that you can easily store an item by using the 'key' parameter, and the other way around get the content of a specific element by calling it with the 'key'.

At least that's way I do.... for other uses or if I want to use the sorting commands of PB I'm using linked lists (which work without a key).

If I'm strictly using maps with a key, its elements can be called easily by a unique key.
But if there (by an accident) is a call of the map with an empty key (empty string or uninitialized string), this would add another map element (without my knowledge then). This could cause hard to find bugs in your program, for which you become aware at a later point...

I would vote to forbid map elements with an empty key (what's the use of a map then, compared to a linked list?), but at least a compiler warning should be added.

See examples and further discussion here: http://www.purebasic.fr/english/viewtop ... 2&start=21

Thank you

Further discussion is welcome, if you see other points about this topic.

[nco2k]

many moons ago, i submitted a bug report, and also briefly mentioned this "issue". when fred fixed the bug, he also made maps no longer accept empty strings as the key name. but then freak and fred had a discussion, and he revoked the change. now in hindsight, im glad that he did. an empty string is still a string, and its perfectly valid to use it. in some cases you might want to use it as the root element. if you need to avoid this, then you should check if the string is empty, before actually using it. forcing this on every programmer, would only make things more difficult, for the ones that actually rely on it.

c ya,
nco2k

[HanPBF]

Both of You are right.
Maybe a flag in NewMap does the job?

[Mistrel]

There's nothing wrong with an empty key. Sanitize your inputs and throw and error there.

The only problem I ever have with maps is in Java where both the key and the value can be null. Eww.

[Andre]

Thank you for your comments!

So there seems to be a reason to allow also empty/uninitialized strings as map keys. If so, ok!

And of course I can check the map key first, if it's a non-valid key (in my case, where I'm using unique ID numbers as key, all empty strings are forbidden). But I can avoid this "overhead", if there would be either
a) an optional parameter to NewMap to forbid such empty strings
b) a compiler warning so I would detect the problem during development.

And furthermore there should be some comments about such cases in the PB manual.

Maybe an implementation would be also possible together with introducing integer variables are possible map key (currently I'm always converting the integer ID numbers into strings to use them for the structured map...

[skywalk]

I prefer PB's Maps accept all strings as keys and "" is a string.
Can you explain what error this option would prevent?

[Andre]

I prefer PB's Maps accept all strings as keys and "" is a string.
Can you explain what error this option would prevent?

It's no problem, if you and other people find the empty strings good as map keys. They shouldn't be forbidden then...

So we speak more about a compiler warning I think...
What my goal was/is: If I'm regularly using maps only with unique "Key ID numbers" (like "1", "2" and higher) there is no place for empty key strings. If I'm calling a map element (by accident of course) with an empty key string, the map was extended by this one element. I searched hours to find the bug in my code....

Of course I can check my key string (to not be empty) always before calling the map element, but this seems to be much overhead (performance loss). That's why I came up with this feature request - if this doesn't have any other disadvantages such an optional parameter to NewMap like

Code: Select all

NewMap Name.<Typ>([Slots [, #OnlyNonEmptyKeyStrings]])

(of course there must be a better word ) could activate a compiler warning if an empty string is used as map key.

[skywalk]

Can you delete the map element for key = "" before you begin, instead of checking for every instance?

Code: Select all

NewMap myMap()
myMap("") = 1
If FindMapElement(myMap(), "")
  Debug MapSize(myMap())
  Debug myMap("")
Else
  Debug MapSize(myMap())
  Debug myMap("")
EndIf
DeleteMapElement(myMap(), "")
If FindMapElement(myMap(), "")
  ; Skipped because deleted.
  Debug MapSize(myMap())
  Debug myMap("")
Else
  Debug MapSize(myMap())  ;<- Returns 0
  Debug myMap("")         ;<- Returns 0
EndIf

[Andre]

Yes, this seems like solution (still to be tested). Thank you for the tip!

Now it's up to other users if there's a need for my initial request....
(because I still see no reason for using empty map keys, but that's my opinion)

[nco2k]

a) an optional parameter to NewMap to forbid such empty strings.

the "overhead" would still exist. the map-library would have to internally check wether or not the key is "", whenever you attempt to add an element. i dont think thats a good idea.

b) a compiler warning so I would detect the problem during development.

i dont think thats a good idea either. a warning implies that you might be doing something wrong, but an empty string is perfectly valid.

I still see no reason for using empty map keys, but that's my opinion

if you want for example to have a map, where you use file-extensions as the key name ("bmp", "jpeg", etc.) a file doesnt have to have a file-extension, so you would use "" as the key name.

c ya,
nco2k

[Andre]

@nco2k:
You're right about the file-extensions.

And of course there shouldn't be created an "overhead" for the map library or similar.

What I thought und still think is: activated by an optional parameter the empty strings can be declared as non-valid, and then a compiler (or better a debugger?) warning will be raised during executation if such an empty string occurs. Of course there shouldn't be any slow-down for the final executable because of my wish...

If Fred or freak say this is not possible or not worth the effort, we can close this request...

[Mistrel]

Why don't you just check the value of the key before putting it into the array?