[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Phillip J. Eby]

At 12:19 PM 5/16/2007 +1200, Greg Ewing wrote:
>Christian Tanzer wrote:
> > Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> >
> > > Phillip J. Eby wrote:
> > >
> > > > Imagine what would happen if the results of
> > > > calling super() depended on what order your modules had been 
> imported in!
> > >
> > > Actually, something like this does happen with super.
> >
> > This is true but doesn't matter (which is the beauty of super).
>
>Only because super methods are written with this
>knowledge in mind, however. Seems to me you ought
>to have something similar in mind when overloading
>a generic function.

This discussion has wandered away from the point.  Next-method calls 
are in fact identical to super calls in the degenerate case of 
specializing only on the first argument.

However, the point of before/after methods is that they don't follow 
this pattern.

If only one person is writing all the methods in a generic function, 
they don't have much benefit from using before/after methods, because 
they could just code the desired behavior into the primary methods.

The benefit of before/after, on the other hand, is that they allow 
any number of developers to "hook" the calling of the function.  Any 
given developer can predict the calling order for *their* before and 
after methods, but does not necessarily know when other developers' 
before/after methods might be called.

If you and I both define a @before(foo,(X,Y)) method, there is no way 
for either of us to predict whose method will be called first, even 
though we can each predict that our own (X,Y) method will be called 
before an (object,object) method that we also registered.  Our 
methods are in parallel universes that do not overlap.

This is the driving force for having before and after methods: 
allowing independent hooks to be registered, while ensuring that they 
can't mess anything up (as long as they stick to their own business).

To put it another way, if you care about the *overall* (absolute?) 
order, you have to use primary or "around" methods.  If you only care 
about the *relative* order, you want a before or after method.  The 
fact that you do NOT have explicit control over the chaining is the 
very thing that makes them able to be independent.