[PEAK] Method replacement and ambiguity resolution using next_method

[P.J. Eby]

At 02:23 PM 8/21/2010 +0200, Christoph Zwerschke wrote:
>Am 20.08.2010 20:49 schrieb P.J. Eby:
>>However, at least currently, it seems like use of "next_method" is
>>rare, so these cases are unlikely to be hidden.
>>
>>Your thoughts?
>
>Hm, I already disliked the next_method parameter for it's original 
>purpose, and I also fear that people will add it now just for 
>indicating the relaxed behavior.

I was worried about that too, but it seems to me that if people want 
relaxed behavior, they will find a way (e.g. by writing a 
prioritized_methods package).  ;-)

As I've been thinking about how I would document it, I think this 
approach is probably the best fit with explaining things in terms of 
"subclassing functions", or monkeypatching.

If you monkeypatch an existing function or method, you will generally 
keep track of the original (i.e. next_method), so you can call 
it.  And, if more than one such patch is applied, each later one 
chains to an earlier one.

So, by analogy, if you are adding a rule that overlaps or equals a 
previous rule, that's like monkeypatching it.

Therefore, by implying that using next_method to redefine an existing 
rule or resolve an ambiguity is like monkeypatching, it will be 
implied that this is a bad thing vs. defining a more specific method 
(more like subclassing than monkeypatching).  ;-)

Or, to put it slightly differently, when overlap occurs, it is up to 
you to specify whether you overlooked having a more-specific rule for 
the area of overlap, or whether you intend to have a Chain Of 
Responsibility in that area.

I am also thinking of splitting AmbiguousMethods into two 
differently-named subclasses: DuplicateRules and 
ConflictingRules.  DuplicateRules would be when you have methods that 
have logically-equivalent conditions, and ConflictingRules would be 
for partially-overlapping conditions.  (AmbiguousMethods itself would 
be renamed to OverlappingRules, but available under the old name for 
better backward compatibility.)

This would give more information about the nature of the problem, as 
well as suggest a solution.  For DuplicateRules, you would either get 
rid of one of the methods or use next_method on the later 
one...  *and* I can cheaply make RuleDuplication errors occur at 
definition time for identical signatures.

For ConflictingRules, on the other hand, the recommended approach is 
to define a new method with the signature suggested by the error 
itself.  (The intersection of the conditions involved.)  But you can 
also use next_method in that case.

I think that separating and renaming these errors, reformatting them 
to be easily-understood, and having both offer their recommendations 
for a fix (as well as haivng good explanations), should probably be 
sufficient to get rid of the perceived need for priorities in 
situations that don't *really* need them.