On Thu, Mar 17, 2005 at 11:46:52PM +0200, Yuval Kogman wrote:
> I think this should mean $_, and if the user really really really
> wants to do .foo on the invocant, then why not just say:
>
> method bar ($_:) {
> .foo;
> }
Because $_ can change.
method bar ($_:) {
.foo;
map { .baz } 1..10; # whoops
}
> This keeps $_ unambiguosly the 'it', while 'this' is more specific.
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.
> Perhaps i'm sort of forcing this distinction.
>
> However, I wouldn't be too happy with having to do this, though:
>
> method data {
> map { $OUTER::_.process($_) } .things;
> }
>
> or having to name the invocant every time I want to map {}.
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.
> Lastly, what is wrong with
>
> $.method?
As I understand it, $invocant.method and $.method are different. The first
is a public attribute the second is a method call, no? And while all
attributes have an associated method (as I understand, ie. foreach $.foo,
$invocant.foo should always be the same) the reverse is not true.
Foreach $invocant.foo there need not be a $.foo.
If this assumption is incorrect then my argument does collapse.
