Aaron Sherman <ajs@ajs.com> writes:
> On Wed, 2002-07-24 at 12:34, Fisher Mark wrote:
> > > But then sometimes you'd *want* hashing to be based on the
> > > content.
> >
> > OK, I'll bite -- when would you want this behavior? This behavior means
> > that once you change the contents, the hash value would become irretrievable
> > unless you restored the contents of the key. (Is this useful in functional
> > programming?)
>
> That's no more true than in this case:
>
> $x = "abc";
> %h = ($x => 1);
> $x = "123";
>
> %h{"abc"} is still 1, not undefined. So to, in this case:
>
> my @x is Hashed::ByValues = (1,2,3);
> %h = (@x => 1);
> @x[1] += 4;
Personally I don't like the C< is Hashed::ByValues > because it smacks
of spooky action at a distance; I much prefer my notion of C< %h{*@x}
= 1>. And in Perl 6 I have the horrible feeling that C<< %h = (*@x =>
1) >> would expand to C<< %h = (1,2,3 => 1) >>, leading to a hash that
looks like C< { 1 => 2, 3 => 1 } >. Or does the pair constructor
force a scalar context on its lhs?
> %h{[1,2,3]} should still be 1, not undefined.
You see, *this* is why I don't like your proposed notation. You
declared @x as hashed by value, not %h itself, so C<
!exists(%h{[1,2,3]})>. Use C< %h{*[1,2,3]} > and intent is made clear
at the point of use. Which is nice.
> Is this ever useful? Of course! You're just associating a unique
> collection to some value.
That would be a multidimension key then wouldn't it? C< %h{1;2;3} >,
or whatever the notation for that is going to be.
> There are any number of places where you would want to do that.
Which is why we're getting multidimensional keys.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Thread Previous
|
Thread Next