[ 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

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.

Reply via email to