[ Sorry if my replies to this thread have seemed a little disjoint. I just realized I'd unsubscribed myself from p6l last year when I started a $job$ and never resubscribed. So I'd only been seeing fragments of the conversation. Catching up from the archives... ]
Larry's idea of making $_ == $self in methods seems to swing the pendulum the other way. Now its a shame to have to make everything explicit inside map, grep, and short for loops etc... And yes, what about given? My immediate reaction to o.method and c.method was a little bit of the heebie-jeebies but then I remembered hey, I wrote CLASS.pm so I could do CLASS->method and its exactly the same thing, a constant function which returns the name of the class. Then c.method doesn't seem so weird. And if you want to be crazy I suppose you can define your own c() and o() functions. :) Its shorter than $self.method and it solves the $_ ambiguity problem so that's good. Its a shame to lose the even shorter .method for an extremely common task but I'm not going to quibble to much over a single character. What it doesn't solve is the $.method vs .method issue. They look similar but one works on the invocant and one works on $_. Still a trap.
