Re: RFC - Hashing PMC's
On 25 Jul 2002 [EMAIL PROTECTED] wrote:
>
> 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?
Well, it depends on precedence. And I think unary * should have higher
precedence than =>, which, mind you, is not a funky comma anymore.
And if not, that's very wrong, and we shoul do something about it.
Luke
Re: RFC - Hashing PMC's
On 25 Jul 2002 [EMAIL PROTECTED] wrote:
> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> > On 25 Jul 2002 [EMAIL PROTECTED] wrote:
> > >
> > > 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?
> >
> > Well, it depends on precedence. And I think unary * should have higher
> > precedence than =>, which, mind you, is not a funky comma anymore.
> >
> > And if not, that's very wrong, and we shoul do something about it.
>
> But what do commas mean in a hash constructor? Do they even have any
> meaning?
It probably does just what you want. Larry said that you could select how
a hash hashes, including having arbitrary objects as keys. Since an
array (or a list) is a real object, you can probably use it as a key. He
said the _default_ is going to look an awful lot like Perl 5. Of course,
he's given no details on that yet.
And I'm sorry if I misquoted him, but I don't think I did.
Luke
Re: RFC - Hashing PMC's
On Thu, 2002-07-25 at 03:12, [EMAIL PROTECTED] wrote:
> Aaron Sherman <[EMAIL PROTECTED]> writes:
> > 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?
Please, don't get me wrong. I prefer the modifier on the hash as well.
But, my point was to show that there is nothing stopping a module author
from doing this, and there need be no support in the core other than
being able to override the hashing methods on any given object. There
will have to be a "$x.hashkey" or the like, I would think anyway, no?
> > %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.
All true.
