Hooks, aspect-oriented programming, and design by contract

[Pedro Rodriguez]

"Alex Martelli" <aleax at aleax.it> wrote:

> "Pedro Rodriguez" <pedro_rodriguez at club-internet.fr> wrote in message
> news:pan.2002.01.22.16.08.43.505728.1637 at club-internet.fr...
>     ...
>> As Alex pointed, 'metaclasses' are maybe the next step. BTW, there are
>> the examples in Demo/metaclasses that may help, you'll even find an
>> Eiffel class implementation for pre/post conditions.
> 
> I also point out that I don't know how to switch metaclasses
> dynamically, temporarily and "retroactively" (i.e. so that
> already-existing instances are also affected), as requested by the
> original poster.  I don't even know if such a metaclass-switch scheme is
> possible at all.
> 
> Note also that the sources in 2.2's Demo\metaclasses are pretty old; I
> think that 2.2's innovations make things quite a bit better now
> (although the old stuff should keep working).
> 
> Still, metaclasses (particularly in 2.2) are no doubt the way to go,
> when it's not dynamic/temporary/noninvasive behavior that you are after,
> but, rather, some kind of permanent behavior modification.

So my questions are : 
- 'aspect, what for ?'
- 'metaclass, what for ?'

My guesses :
- metaclass is used to define class templates so that all classes exhibit
  the same design (like the example in descintro on autosuper, autoprop, 
  or the example posted on post/pre/invariant conditions).
- when you define a class relying on a metaclass, what the metaclass does
  for your class must be known to the user of the class (say it is part
  of its contract)

- aspect is to factorize a behaviour at some points of the application
  (near methods entry/exit point)
- it may be done to capture a design feature but this is not mandatory
- an aspect is not part of the 'contract' of a class since a class is
  not aware of the aspects that have been put on it
- an aspect may be part of the 'contract' of an overall design

Technically, both will involve class modification (by method wrapping,
attribute addition). 

When will these modifications take place :
- dynamically and retroactively : no (too much tracking)
- temporary : no (will need a registering scheme, except for debugging
  purpose won't be of any interest, and even for debugging there are
  simpler way to activate/deactivate it)
- static : yes, at startup for aspects, at class/instance creation for
  metaclasses. This is part of the design of the application.

Should C extensions provide such a mechanism ? No, keep the extension
simple, and provide a Python wrapper will can be overriden.

Should aspects be based on metaclasses ? No, they don't have the same
purpose. Maybe there could be some interest to define a metaclass to
help tracking Pointcuts or setting advices, but I don't think this is
mandatory.

Regards,
-- 

Pedro