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
