On 11/30/05, Roph <Roph at kc dot rr dot com> wrote:
> there's a difference in having a case-senstive hash so
> that it is highly unlikely that you have to ever incur the processing
> overhead for dealing with a collision, and having a case-insensitive hash
> that guarantees you'll have to invoke your hash collision logic frequently
> and repeatedly because all uses of "text", "TEXT", and "Text" will
> necessarily hash to the same value.
I agree with Joe here - you'll have to deal with collisions anyways,
and having case-sensitive hashes only changes the performance.
HOWEVER - where this really hurts is if you try to use a RB's
Dictionary class, which builds upon these Hash values. While a
Dictionary does manage collisions and creates a list of colliding but
different keys, it will not see case-only-different strings as
different strings.
So, if you try to store two keys "a" and "A" in a dictionary, you're
not getting it done without extra work, and the solution to this
really awkward. I.e, some here suggest that you could encode your keys
as Base64 so that you can store them like case-sensitive strings. But
THAT is a big hit in performance that's way worse than what you have
to face if you're dealing with your Hash values, I'd say.
Many have complained about this, but still there's no RB-provided way
to use binary string keys without such a unnecessary performance hit.
And here, I agree fully with your perception of how the replies from
RS sound to you: If RS sees not need for it, then their users' need
can't be real, either.
--
Thomas Tempelmann - exaggerating over a million times a day!
http://www.tempel.org/rb/ -- The primary source of outdated REALbasic
plugins and examples
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|