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.


Reply via email to