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 ($_:) {
                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.

Reply via email to