HaloO,
Smylers wrote:
But why would a hash be doing equality operations at all?
I think it does so in the abstract. A concrete implementation
might use the .id method to get a hash value directly.
Assuming that
a hash is implemented efficiently, as a hash, then it needs to be able
to map directly from a given key to its corresponding value, not to have
to compare the given key in turn against each of the stored keys to see
if they happen to match under some special meaning of eq.
You snipped Ruud's next bit:
Or broader: that the keys should be normalized (think NFKC()) before
usage?
As $Larry pointed out, this all boils down to getting the key type
of the hash wired into the hash somehow. Assuming it dispatches on
the .id method the following might do:
class CaseInsensitive does Str
{
method id { self.uc.Str::id }
}
my %hash{CaseInsensitive};
As usual the compiler might optimize dynamic method lookup away
if the key type is known at compile time.
That seems the obvious way to implement this, that all keys are
normalized (say with C<uc>, for this specific example) both on storage
and look-up. Then the main hashy bit doesn't have to change at all.
Yep. But the @Larry need to confirm that the Hash calls .id on strings
as well as on objects. Note that Array might rely on something similar
to access the numeric key. Then you could overload it e.g. to get a
modulo index:
class ModuloIndex does Int
{
method id { self % 10 }
}
my @array[ModuloIndex];
--
