Hi,
From my point of view hash is a way to obtain data value by key value (not
by number like in array).
To be precise: hashes allows to operate non continuous on indexes.
These indexes does not have to be strings.
F.e. AFAIR you are using pointers.
Yes, I know keys can be also numeric. Perhaps it's a lack of english
knowledge to express the difference between a hash and array in a clear
way. I'm using all type of hash keys, not only pointers.
So, I do not understand at all, why do we need hb_hSetBinary() and
hb_hBinary()?!It should be hash's internals and users should not care about
it!
I fully agree. But I didn't want to discuss about it. I still remember from
my xHarbour days discussion about keeping build order in hashes for
replicating associated arrays class behavior.
If we can agree that we do not need backward internal order compatibility
then I'll be very happy in removing hb_hBinary().
AFAIR, the problem with xHarbour was, that in the beginning it does not
had a hash and TAssociativeArray() was used. Later hash implementation
has changed it, and for backward compatibility some side effects was
replicated in hashes. I believe we do not need to follow backward
compatibility of xHarbour's TAssociativeArray(), I like solutions
without side effects.
But please do not forget about one thing. National sorting can cause
that two different keys will be equal in some languages. It's the same
problem like with CASEMATCH flag.
Well, I did not know such things. After such know knowledge I'll be
afraid to use ==. Perhaps, I'll write my own string_[binary_]equal() :)
I really do not know what is the best solution in this case, but I see
binary comparison most natural.
Best regards,
Mindaugas
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
