Damian Conway: # Larry revealed: # # > : method bar($me : *@_) { # > : ... # > : } # > : # > : will use $me instead. # > # > That is the approach I currently favor. (Though I'd # probably leave # > out the space in front of the colon.) And it has the # advantage that # > $me is automatically assumed to be read only. # # # Okay, so let's clarify: # # 1. If you declare a method *with* a colon separator in # its parameter # list: # # method foo ($self: $foosrc, $foodest, $etc) {...} # # then the parameter before the colon is bound to the invocant, # and the parameters after the colon are bound to the other # args of the method call. # # # 2. If you declare a method *without* a colon separator in its # parameter list: # # method foo ($foosrc, $foodest, $etc) {...} # # then the parameters are bound to the non-invocant # args of the method call and the invocant itself is # inaccessible (except implicitly through the unary dot # operator). # # # 3. If you declare a method *without* any parameter list: # # method foo {...} # # then the method call arguments (including the invocant?) # are bound to @_.
What about the case where you want method 'bar' to be called like C<< $obj->bar($a, $b: $c, $d) >>? It would seem unfair to ban the use of colon on method calls, or to make you declare a self; perhaps: method bar($a, $b: $c, $d) { ... } That still leaves the case of C<< $obj->bar($a: $b, $c) >>. Perhaps: method bar(: $a: $b, $c) would work for that? --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 When I take action, I’m not going to fire a $2 million missile at a $10 empty tent and hit a camel in the butt. --Dubya