At 04:31 PM 5/13/2007 +0200, Christian Tanzer wrote:
>"Guido van Rossum" <[EMAIL PROTECTED]> 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.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
