Larry Wall wrote:
Maybe we need to allow the & indirection on method names too:if $obj.&fribble:(Str --> BadPoet) {
-snip-
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 names. 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
