Metaclasses vs. standard Python reflection?

[Russ Salsbury]

mis6 at pitt.edu (Michele Simionato) wrote in message news:<2259b0e2.0305020517.67b88b00 at posting.google.com>...
> 
> Some time ago, I read a paper about AOP. Maybe that paper was particularly
> bad, but these were my impressions:
> 
> 1) I couldn't manage to distinguish between the buzzwords and the actual
> information;
> 
> 2) the examples were too abstract and saying nothing to me;

I've read 3 or 4 papers, so maybe I can shed some light. ;-)
The AspectJ homepage is http://www.eclipse.org/aspectj/
www.aosd.net -- the AOP homepage is now password protected. 
Definitely unfriendly. Also AOP seems to be under the umbrella term
"Adaptive Programming".

The motivating idea is that while an algorithm may be easy to
understand, it can be downright impenetrable when you add
synchronizaion, exceprion handling, and the like.  To make the code
clearer and easier to implement, aspects (synchronization, eiffel
contracts, ...) are separated into separate files, coded in the
AspectJ extensions to Java.  The AspectJ preprocessor takes the
aspects and the Java and "weaves" the "tangled" code (their words :-).
 Chapter 2 of the the language manual on the eclipse site gives a
pretty clear example.  (Well maybe clear if you have thought about
this style of programming before. ;-)

If the Java example seems a little contrived, take a look at the C++
examples in Ch. 8 of "Generative Programming" by Czarnecki and
Eisenecker.  It makes AOP look like an idea whose time has come. (It's
a good survey of the program generation art.  If your interest lies in
that direction, I recommend it.)

I think part of the problem of clarity is that these are new concepts
to most of us.  I submit the recent discussions of metaclasses as
evidence.  ;-)  I have been thinking about some of these things for
years (even implementing them) and still my brain gets tied in knots.

> 3) the part I understood, I could have implemented trivially with
> Python metaclasses, without any need to go through a new programming
> language such as AspectJ.

AspectJ is a little more powerful, because it can be more fine grained
than metaclasses.  For example, you can apply guards (like
synchronization) to assignment statements. But in general you are
right.
 
> 4) I had the impression they were introducing many ad hoc concepts to
> solve specific problems, whereas a general purpose solution such as
> a metaclass would have solved everything in a much clearer and customizable
> way for the final user.

I think the paper you read was on an earlier version because that was
certainly true then.  Worse even, because each specific problem had
its own aspect language.  The version at eclipse is a little more
general.  But again you are right; all the AOP style technologies
seemed to have started as general solutions to specific problems.  I
believe it's Demeter that is a program generator for tree walking
problems.  The Visitor Pattern has its own programming language!
 
> Of course, I only have read one paper and I could well be wrong. 
> My position (due the reading of that only one paper, could change
> in the future) is that the problems AOP is trying to address are 
> important; nevertheless, that paper did not convince me that the AOP 
> solution was the right solution.
> 
> There is nom doubt that metaclasses are the right solution <0.5 wink>

I agree with you.  I lost interest in AOP after it became Java
specific (at Xerox PARC at least). The weakness that I see in AOP is
that appears to be applied to specific classes (wild cards allowed). 
OTOH metacalsses are part of class composition like inheritance is. 
To be more specific: in the AOP scheme of things you could write a
program using the stack class, and then at some arbitrary point in the
future create a synchronization aspect, run AspectJ, and presto
changeo you have a synchronized version without touching your original
program.  With metaclasses you would create a new syncstack class
inheriting from stack and using the sync metaclass.  They are
certainly different ways of tackling a problem.

The interesting thing about metaclasses (and python in general) is it
gives us a simple way to tackle some very hairy problems.  Contrast
that with AOP where many reachers at a number of universities have
spent nearly a decade to come up with a very elegant solution to a
subset of the same problems.  (Acutually there are a number of big
academic solutions to the same set of problems.)

I expect that as pythonistas start using metaclasses some very elegant
methods for specifying metaclasses will emerge.  Then someone will
invent AspectP.  Solve the problem, then make the solution elegant. 
Very Pythonish.

My candidate for needs-an-elegant-solution is how to specify metaclass
composition.

Take a look at "Putting Metaclasses to Work" by Forman and Danforth
for ideas on the use of metaclasses, although you will have to slog
through C++ and an excessive need to be mathematically formal.

-- Russ