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

[Phillip J. Eby]

At 10:16 AM 5/3/2007 -0400, Jim Jewett wrote:
>On 5/3/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> > I don't doubt that things like @before and @after are
> > handy. But being handy isn't enough for something to
> > get into the Python core.
>
>I hadn't thought of @before and @after as truly core; I had assumed
>they were decorators that would be available in a genfunc module.

Everything in the PEP is imported from an "overloading" module.  I'm 
not crazy enough to try proposing any built-ins at this point.


>(2)  The explicit version of next_method corresponds to super, but is
>uglier in practice, becaues their isn't inheritance involved.  My
>strawman would boil down to...
>
>     def foo():...
>         next_method = GenFunc.dispatch(*args, after=__this_function__)

Keep in mind that the same function can be re-registered under 
multiple rules, so a reference to the function is insufficient to 
specify where to chain from.  Also, your proposal appears to be 
*re-dispatching* the arguments.  My implementation doesn't redispatch 
anything; it creates a chain of method objects, which each know their 
next method.  These chains are created and cached whenever a new 
combination of methods is required.

In RuleDispatch, the chains are actually linked as bound method 
objects, so that a function's next_method is bound as if it were the 
"self" of that function.  Thus, calling the next method takes 
advantage of Python's "bound method" optimizations.


>Note that the overriding function foo would need to have both a
>reference to itself (as opposed to its name, which will often be bound
>to somthing else) and to the generic function from which it is being
>called (and it might be called from several such functions).
>Arranging this during the registration seems like an awaful lots of
>work to avoid @after

Yep, it's a whole lot simpler just to provide the next_method as an 
extra argument.