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

[Greg Ewing]

Phillip J. Eby wrote:
> At 07:48 PM 5/2/2007 +1200, Greg Ewing wrote:
 >
> > I'd work on that by finding ways to reduce the boilerplate.
> 
> Um...  I did.  They're called @before and @after.  :)

I was talking about the need to put extra magic names
in the parameter list just to be able to call the next
method.

> I notice that you didn't respond to my point that these also make it 
> easier for the reader to tell what the method is doing,

No, it doesn't. It tells you a very small amount about
*how* the method does whatever it does. To find out
*what* the method does, you have to either read the
comment/docstring, or if it doesn't have one, read the
method body anyway. If you read the body, you'll notice
whether and when it calls the next method.

In other words, I see the calling of the next method
as an implementation detail that doesn't need to be
announced prominently at the top of the method.

> Meanwhile, it takes less than 40 lines of code to implement both @before 
> and @after;

Size of implementation isn't the issue, it's the mental
load on someone trying to learn all this stuff and keep
it in their head. It's a lot easier to learn and retain
knowledge about one general mechanism than five or more
special-case variations of it.

> """In short, you have to ask yourself: am I hooking something 
> (before/after), implementing it (when), or just generally looking for 
> trouble (around)?"""

There are a lot of other things you have to ask yourself
before writing your method, too. I don't see this particular
question as fundamental enough to pick out for special
treatment.

> You seem to be confusing Common Lisp with CLOS.  They are not the same thing.

You're right, my comment was really about Common Lisp as
a whole. But if they can't even keep the basic Lisp dialect
clean and coherent, it doesn't give me confidence that
they've made any attempt to do so with its object system.

More generally, arguments of the form "Language X does
it this way, so it must be good" don't impress me if I
don't regard language X as being particularly well
designed in the first place.

> Meanwhile, AspectJ and Inform 7 also include before/after/around advice 
> for their generic functions, so it's hardly only CLOS as an example of 
> their usefulness.

I'm very skeptical about the whole business of aspects,
too, and I find Inform 7 to be massively confusing in
many ways. So you're not going to impress me by appealing
to those, either. :-)

--
Greg