[PEAK] Rules override

[Phillip J. Eby]

At 10:07 PM 3/1/2008 +0200, Sergey Schetinin wrote:
>Not exactly, the difference is when the ambiguity occurs, `override'
>just uses the first one defined. I can't find a better way to
>implement multiple dispatch where some of the rules have the priority
>over all the other ones and ambiguity is ignored (assumed to be
>handled by the methods themselves). See my example in the last
>message.

Yes, I saw it, and I don't understand the use case or why you want to 
ignore ambiguity or think you can assume it "to be handled by the 
methods themselves".  (And your example was achievable with 'around' 
methods as soon as you got rid of the list/list ambiguity -- a good 
thing to do in any case.)

Note that even "before" and "after" methods with the same criteria 
are not truly ambiguous - they use definition order and 
reverse-definition order to break the ties (using the "precedence" 
argument, which is a sequentially-generated number).

And, without a clear use case for it, I don't plan to add another 
ambiguity-resolving method type.  In general, new users are far too 
quick to want to resolve ambiguity by precedence hacks, when they 
should be thinking more deeply about what they are trying to 
express/accomplish.  Often, a slight refactoring of the function 
signature or rules creates more clarity in the application, as well 
as resolving the ambiguity.