Hi Mindaugas, Przemek,
Do you mean this? :
h := hb_hSetReturnKeyIfKeyDoesNotExistInHash({=>}, .T.)
? h["aaa"] // prints "aaa"
h["aaa"] := "bbb"
? h["aaa"] // prints "bbb"
I do not want to be stopper for new ideas, but I do not see this
flag (and possibility to return key value, if hash does not contain
this key) useful for general hash usage. Ok, it's good for i18n
translation, but do we know any other places it could be usefull? We
will need to write some i18n C code, this h[cKey] => cKey behaviour
could be implemented in i18n_gettext() function.
Syntax h[ @cKey ] gives possibility to test if array index is passed
by reference in virtual machine, but I think it's alien syntax. User
can never guess that passing by reference imply default return of
value cKey.
I see the only useful (natural, widely used) extension for hashes.
It is HB_HGET() extension:
HB_HGET( hHash, xKey [, xDefaultValue ] )
Nice. But do you mean that if xDefaultValue is passed, we
should change the RTE behavior of this function? It's okay-ish
with me, but it's a bit strange. For me it would be the
most natural if this function would simply return NIL in
case the key isn't found, or xDefaultValue, if passed. But
changing this function may cause compatibility concerns for
some users (I can't judge).
What was the reasoning behind adding an RTE for non-existing
key lookup, does anyone have any memories on that?
It could be used not only in i18n context: HB_HGET( hHash, cKey,
cKey ), but also in other places. For example, if I store .ini file
content in hash, and want to get some application settings:
nPort := HB_HGET( hIni, "Port", 80 ),
nW := HB_HGET( hIni, "DefaultScreenWidth", 1280 ),
etc.
Absolutely.
Of cause, HB_HGET( hHash, cKey, cKey ) is not speed optimal (cKey
parameters is passed twice), but if we want to chase for i18n string
lookup speed, we will need to implement i18n_gettext() in C anyway.
So, .prg level function HB_HGET() will not be used in implementation.
I agree.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
