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

[Phillip J. Eby]

At 04:31 PM 5/13/2007 +0200, Christian Tanzer wrote:

>"Guido van Rossum" <guido at python.org> wrote:
>
> > - Expect pushback on your assumption that every function or method
> > should be fair game for overloading. Requiring explicit tagging the
> > base or default implementation makes things a lot more palatable and
> > predictable for those of us who are still struggling to accept GFs.
>
>Front-up tagging might make it more palatable but IMHO it would be a
>serious mistake.
>
>I still shudder when I think of C++'s `virtual` (although it's been a
>looong time since I stopped using C++ [thanks, Guido!] :-)

It's not *that* serious.  Even if we end up with the stdlib-supplied 
version having to pre-declare functions, it'll be trivial to 
implement a third party library that retroactively makes it unnecessary.

Specifically, the way it would work is that the 
overloading.rules_for() function will just need a "before" overload 
for FunctionType that modifies the function in-place to be suitable.

So, people who want to be able to do true AOP will just need to 
either write a short piece of code themselves, or import it from 
somewhere.  It'd probably look something like this:

    from overloading import before, rules_for, isgeneric, overloadable

    @before
    def rules_for(ob: type(lambda:None)):
        if not isgeneric(ob):
             gf = overloadable(ob)  # apply the decorator
             ob.__code__    = gf.__code__
             ob.__closure__ = gf.__closure__
             ob.__globals__ = gf.__globals__
             ob.__dict__    = gf.__dict__

The idea here is that if "@overloadable" is the decorator for turning 
a regular function into a generic function, you can simply apply it 
to the function and copy the new function's attributes to the old 
one, thereby converting it in-place.  It might be slightly trickier 
than shown, but probably not much.