Hi Przemek,
We can use any algorithm for sorting keys. We can also use the real
hashing
algorithm, i.e. generate some checksum of key, and try to find
value using
this checksum. In this case national/binary sorting is not used at
all.
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().
You have my vote for it.
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. So hb_hBinary() does not only change
the internal item order but also keys hashing method.
I think this just leads to possible misunderstandings.
IMO two different strings should be different regardless of
national settings. If we want 'sorted array' feature with
quick find support, that's a different thing and should be
discussed/implemented outside hashes.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
