[PEAK] Rules override
Phillip J. Eby
pje at telecommunity.com
Sat Mar 1 16:40:26 EST 2008
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
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.
More information about the PEAK