[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc. (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Thu May 3 02:38:46 CEST 2007

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

More information about the Python-3000 mailing list