Larry Wall wrote:
Maybe we need to allow the & indirection on method names too:

    if $obj.&fribble:(Str --> BadPoet) {


Note that we already define &foo:(Int, Str) to return a list of candidates
if there's more than one, so extending this from the multi dispatcher
to the single dispatcher just seem like a SMOS (small matter of syntax).

One corollary of this is that querying an object for its available
methods should probably give you a list of coderefs instead of method

What threw me initially was that I wasn't used to thinking of a
coderef as a test for existence - in particular, I couldn't see how
the method's name could be specified using such a syntax.

Another question: what about

 $obj.?fribble:(Str --> BadPoet)
 $obj.*fribble:(Str --> BadPoet)
 $obj.+fribble:(Str --> BadPoet)

As I understand it, placing a ? or * between an object and a method
results in the method only being called if it exists (although I'm not
clear on what happens if it doesn't); placing a * or + between the
object and method calls every version of the method that applies.
Couldn't you just cap one of the former two with a '&' to prevent the
resulting methods from actually running?

 &$obj.?fribble:(Str --> BadPoet)
 &$obj.*fribble:(Str --> BadPoet)
 &$obj.+fribble:(Str --> BadPoet)

Or would you have to hyperize the '&' in the latter cases?

 &$obj.fribble:(Str --> BadPoet) # dies if fribble doesn't work as advertised;
 &$obj.?fribble:(Str --> BadPoet) # returns undef instead.
 &«$obj.*fribble:(Str --> BadPoet) # returns a list of all fribbles;
 &«$obj.+fribble:(Str --> BadPoet) # as above, but fails on an empty list.

Regardless, I agree: can '.can()'.

Jonathan "Dataweaver" Lang

Reply via email to