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.