--- Brent Dax <[EMAIL PROTECTED]> wrote: > I suggest that we might require a special property to say "dispatch > on return value", which would give us a place to put in some > information to resolve conflicts.
In keeping with the notion of "a language for good programmers," I think that the very act of defining two methods which are equivalent in all but name is pretty much a deliberate statement of intent to "dispatch on return value." Perhaps an "is ambiguous" keyword to stuff the warning which we should, in all fairness, emit for those who didn't actually mean what they typed. In the event that two modules export functions that collide, the warning should prompt the user to add: Dog bar($p is int) is ambiguous is default; ====== 10 minutes and a visit to RFC-land later, I have some guy named after a 70's comedian writing: http://dev.perl.org/rfc/256.html#Handling_dispatch_failure However, experience indicates that sometimes the more specialized variants of a multimethod are only provided as optimizations, and a more general variant (in this case, the (Peg,Hole) variant) would suffice as a default where such an ambiguity exists. It is proposed that an additional parameterized attribute -- :default(ambiguous) -- be provided so that one particular multimethod can be nominated as the dispatch recipient in cases of ambiguity: sub put_peg(Peg,Hole) : multi default(ambiguous) { print "some kinda peg in some kinda hole\n" } Now, whenever a call to put_peg can't be dispatched because it's ambiguous, this default variant will be called, rather than throwing an exception. ====== Man, it gripes my wagger when he gets there first... :-/ Where two xyzzy functions could invoke different bar functions, the list of bar() multis to invoke is as above, and the dispatch distance is 1 in each case. So either there is a C<bar(?) is default(ambiguous)> or there's an exception. Look, the water still beads! =Austin
