[PEAK] Rules override

[Phillip J. Eby]

At 10:48 AM 3/2/2008 +0200, Sergey Schetinin wrote:
>A better way to implement this, I think, would be a method type that
>can change the parameters passed to the function

Indeed.  Of course, you could also implement your use case by 
splitting the add operation into two GFs (which is probably what you 
were doing in effect with PyProtocols, by adapting the adder and 
addee to a pair of protocols).

If I were going to implement this method type, I would probably call 
it "conversion" or "adapting" or something to indicate the 
transformative use.  I also think I would want to have it specify 
*which* argument is being converted, and require non-ambiguity of 
criteria between methods that applied to the same argument.

Even so, there would still be the problem of which argument should 
take precedence, among conversion methods.  What if more than one 
argument needs conversion?

And what should the precedence be between conversion vs. other 
operations?  Many of the use cases for before/after/around methods 
are such that it's not clear whether conversion should take place 
first or not, depending on how you want to treat multiples.

So, while I'm a bit clearer now on the use case, I'm not yet clear 
enough on what the right design should be, and I'm definitely not 
convinced that ambiguity should be allowed.

The problem with allowing ambiguity is that it's way too easy to end 
up writing code whose correct behavior depends on runtime conditions 
that could change if say, the order of module importing 
changes.  Thus, you could have code that appears to work perfectly 
suddenly blow up and do something crazy.

I am therefore very hesitant to allow even very controlled 
ambiguity.  Even if the person who initially creates the code is sure 
it's okay, there will be people who will copy their example without 
thinking or reading any docs, and then will gripe and complain about 
how unreliable the rule system is.  And then I will be very sad.  ;-)