Michael G Schwern skribis 2005-03-17 14:42 (-0800):
> Because $_ can change.
> method bar ($_:) {
> .foo;
> map { .baz } 1..10; # whoops
> }
The problem here is not specific to methods.
It is generic to all nested uses $_. We used to see this mostly with
nested foreaches, but now we get methods too.
The solution is also generic for all these situations: either use
$OUTER::_ or give the outer $_ another (second) name.
This is consistent, easy to learn and easy to work around, especially
now that Perl has an easy syntax for aliasing.
> I'm not proposing changing what $_ means, I'm proposing changing what .method
> means. Instead of $_.method make it mean $invocant.method. Sooo I'm not
> really sure where all that extra stuff about $_ was going, true as it may be.
That will be very weird if you still want .<foo> to work on $_. The same
prefix operator will then have two possible implied invocants. I think
of <> as a postfix *method* rather than an operator, and would want this
to be consistent.
> Right. I believe the times one will want to do a method call on $_ when it
> is *not* the invocant will be greatly outnumbered by the times when you
> want to do a method call on the invocant. Thus adding ambiguity to .method
> is not worth it.
I don't believe this, especially because I read subscripting as methods.
Isn't the whole problem solved by using dotless syntax for calling a
method on the current invocant? If calling methods on the invocant is
indeed more common, then Huffman will like this. I haven't looked into
possible clashing with subs/multis yet.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
