On 23 Jul 2002, Alberto Manuel Brand�o Sim�es wrote:
> On Tue, 2002-07-23 at 09:27, Ashley Winters wrote:
> > On Tuesday 23 July 2002 07:47 am, Alberto Manuel Brand�o Sim�es wrote:
> > > Now, I ask for PMC programmers to take care implementing this! Notice
> > > that, for example in arrays, arrays with the same length but different
> > > elements should return different hash codes (or try). But for the same
> > > elements MUST return the same hash code.
> >
> > @foo = ();
> > %hash{@foo} = 10;
> > push @foo, 'This would change the hash key for @foo?';
> >
> > print "ok 1" if exists %hash{ [] };
> > print "ok 2" if exists %hash{ ['This would change the hash key for @foo?'] };
> > print "ok 3" if exists %hash{@foo};
> >
> > What's going to get printed from that?
>
> IMHO, it should print 'ok 1'. The idea of the hash function is to use
> PMC's as hash keys. That means that different content PMC (as an array
> with different elements) must return different hash keys.
I don't know. I think it'd be unexpectedly inefficient to recursively
compute hash keys. I guess a PMC can decide for itself how it computes
them. However, in my most recent project, I found it very useful to hash
the references (like perl5 does by stringifying them). There were
identical arrays, but they had different addresses, and it wouldn't have
worked if they hashed to the same value.
BTW, the project was building a GraphViz graph of an NFA.
Let's think practically: how many times will we need to hash on array
element identity, and how many on reference identity. I think they're
both arguable cases, so perhaps some way to tell the difference?
Like hashing an array itself would hash the elements, and hashing a
reference would, well, hash the reference. Which means above, nothing
would be printed.
This would inherently allow for multi-dimensional hashes implemented
somewhat like Perl 5's $;, only better.
But, this isn't my area, so that's just my two cents.
Luke
