Metaclasses vs. standard Python reflection?

[Hung Jung Lu]

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;
> 
> 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.
> 
> 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.
> 
> 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>
> 
> 
>                                       Michele

I pretty much have the same feeling about AOP when I went through some
of the papers. The researchers all have some idea of what's going on,
but they all failed to pin-point what exactly the beast is. From my
academic experience, I can tell when a paper is badly written. These
guys are all rushing into publishing, before they have carefully
digested their own thoughts. The results are all half-baked ideas,
buzz words, terrible messy things like "cross-cut", and dubious
improvements to current programming practices. So much blah blah blah,
and the actual basic concept is just in the "before advice" and "after
advice", which in more traditional terms are known as hooks.

I tell you guys what I have in mind. If I err, please let me know.
Maybe this is the beast everybody is after. I think everything goes
back to one of the most feared concepts in programming: self modifying
code, or meta programming. I know, once upon a time it was unthinkable
to work with self-modifying codes. But, to borrow physics buzz words,
you've got first quantization and second quantization, and that seems
like the way how nature works. You have programming and meta
programming. You see it all over places. You have HTML files, and
people soon realize that need something more powerful, and then you
get all server page technologies like ASP / JSP / Zope's DTML, etc.

That's how I view things like hooks. I have again and again run into
need of using hooks. I just posted a message on module reloading and
wxPython. Exception handling can also be implemented via hooks and
meta programming. The thing is, after you write many pages of code,
you realize that you need to do something very similar to many places
of your code. (In the case of exception handling, you want to modify
ALL the call returns in whole stack of function calls.) Or that you
realize you are repeating something similar in many of your classes or
modules, and these similarities simply cannot be factorized by
conventional OOP (what I consider to be equivalent to first
quantization.) So you need something higher ("second quantization"),
known as meta-programming. What you effectively are doing is to modify
your code behavior dynamically. The net result is always equivalent to
a first quantized version at a given moment. Just like if you take a
snap shot of ASP, it's equivalent to a static HTML page. (Of course,
the next time you request it, you may get a different end result.)
Meta programming is the same. At a given moment your program is
equivalent to a static, conventional piece of code. It's just that you
are allowing your code to change as the program runs.

Basically, your program not only work with your data, but with your
codes as well. And you can insert/modify/delete/replace code lines
during run time.

Consider the case of exception handling.


def f(y):
   if y=3: raise Exception
   return 4

try:
   x = f(3)
except:
   print 'error'

This can be equivalent to a piece of code without exception handling:
(I know there are two ways of implementing exception handling, one
more efficient without recursively unwinding of the stack. But here I
am only showing this example for the sake of argument.)

def f(y):
   exception = None
   actual_output = None
   if y=3: 
      exception = True
      return (exception, actual_output)
   actual_output = 4
   return (exception, actual_output)

...
(exception, actual_output) = f(3)
if exception==None:
  x = actual_output
else:
  print 'error'

When you write the exception handlers, basically you are giving
instructions on how the actual code lines can be generated. The
exception tags are meta-programming instructions. Sure, they have
nicer looking syntactic sugar coating, but they are just meta
programming function calls: they grab the code objects around the
spots, and tweak them.

Same thing with metaclasses operation. You want to grab the metaclass
methods and tweak them.

Everything at the end of the day reduces to one change in the
underlying language environment and the enabling of three operations.
The one change is: (I) to expose more of the language's internal
functions. Three operations are: (a) insert a before-hook when calling
a function, (b) replace/overriding a function itself, (c) insert a
after-hook when calling a function. The rest is all buzz words and
syntactic sugar coating.

As my friend a CS professor once told me: there only one single trick
in Computer Science, and that is: "one more layer of indirection". I
guess Aspect-Oriented Programming is no exception.

Hung Jung Lu