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

[Phillip J. Eby]

At 02:50 PM 5/2/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > The PEP lists *five* built-in decorators, all of which support this 
> behavior::
> >
> >     @overload, @when, @before, @after, @around
>
>This seems massively over-designed. All you need is the
>ability to call the next method, and you can get all of
>these behaviours. If you call it first, then you get
>after behaviour; if you call it last, you get before
>behaviour; etc.

Yep, that was my theory too, until I actually used generic functions.  As 
it happens, it's:

1) a lot more pleasant not to write the extra boilerplate all the time, and

2) having @before or @after tells you right away the intent of the method, 
without having to carefully inspect the body to see when and whether it is 
calling the next method, and whether it is modifying the arguments or 
return values in some way.

In other words, the restricted behavior of @before and @after methods makes 
them easier to write *and* easier to read.

By the way, if you look at the PEP, you'll find motivating examples for 
each of the decorators, as well as an explanation and examples of when and 
how you might want to create even *more* such decorators.

IIRC, CLOS has about *8 more* kinds of method combinators that come 
standard, including ones that we'd probably spell something like @sum, 
@product, @min, @max, @list, @any, and @all, if it weren't for most of 
those names already being builtins that mean something else.  :)  The PEP 
doesn't propose implementing all of those, but it does show how easily you 
can create things like that if you want to.