Hooks, aspect-oriented programming, and design by contract

[Pedro Rodriguez]

"Huaiyu Zhu" <huaiyu at gauss.almadan.ibm.com> wrote:

> On Tue, 22 Jan 2002 16:59:12 +0100, 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.
> 
> I'm trying to understand these discussions.  Let me see if I get this
> right. Consider the following snippet
> 
> class A:
>     def method1(self): pass
>     def method2(self): pass
> a = A()
> 
> The objected oriented techniques allow you to subclass A to add more
> attributes, like
> 
> class B(A):
>     def method3(self): pass
> b = B()
> 
> But this will not affect class A and object a.  And if you want to
> change all these methods in the same way, you have to modify them one by
> one.

OO as we know it.

> 
> In contrast, what aspect oriented techniques allow you to do is to
> crosscut through different methods, so that you could, for example, let
> each of the methods printout "calling <methodname>", in one stroke,
> without putting print statements in each of them.  You could do this to
> class A or B or selected subset of methods, and it will affect existing
> objects a and b.
> 

So far that is what I also understand about the concept (at least with my
understanding of AspectJ)

> If you let class A be derived from another class C, which itself is an
> instance of a metaclass, then these aspects discussed above become the
> properties of the metaclass, so you can achieve similar effect by using
> metaclass.
> 

To achieve this effect, you'll need to have spotted the requirement for
such metaclass, not to say several onces, in your design. Still once
spotted, you will need to modify you your base classes to take advantage
of them. So you may achieve the same effect, but taking it into account
is intrusive, to my opinion.

> What you claim don't know is whether the changes to the metaclass can
> affect objects a and b after they have already been constructed.  Or,
> IOW, whether the metaclass is "doubly dynamic" in the sense that changes
> to it not only affect the class A at the time it is created, but also
> all the methods of A when they are used.
> 
> Is the above description essentially right?
> 
> If the metaclasses are "dynamic enough", wouldn't it be possible for it
> to decide, at the time when its instances (ie classes) are created, to
> leave hooks in their methods?  Such hooks would then enable aspects of
> these method calls to be changed later.
> 

Can't answer at the first question ? Regarding the last point, I find it
overkilling since python provides simple means to achieve the same goal.
Wrapping methods as always been feasible without requiring metaclasses.
Have you something else in mind with hooks ?

> Here's a newbie question to aspect oriented experts:

I wish an aspect oriented expert could enlighten us. But once you get the
concept, I think you may twist it to meet your needs just like a design
pattern.


> ... is the set of
> aspects that can be changed predefined?  If so, it seems to me that in
> principle metaclass could do at least what aspect oriented approach
> could do.
> 

Some may be predefined if you take aop in design : for example, I think
this could be realistic in regard of examples read, consider this :
- you have a set of classes representing graphical objects,
- modifying a point, a set of points of an object will require a screen
  refresh
- each method modifying a point should require refreshing

So you can explicitly require refreshing IN each method, or decide that
graphical classes won't deal with this "aspect". You will, as part of
your design, create an 'aspect' that will cross cut updates to perform an
(efficient) refresh of your screen. 

I think that you can achieve the same thing by creating a metaclass to
deal with this 'aspect'. You may need to 'tag' methods (by convention 
naming for instance) dealing with this 'aspect' to 'intercept' those
calls.

Now imagine I want to log all exceptions that may be raised by methods
of all classes (graphical or not). If I stick with metaclasses, I will 
need to create a new one, modify all other design metaclasses so that
they subclass this new one, crossing fingers that there won't name clash
with tagging.

So to answer your question : yes you can achieve the same thing with
metaclasses, but with more effort. Or maybe there should be better way to
use metaclasses than I can think of ?

> I know little about either aspect oriented programming or the current
> status of Python metaclasses, so I may be way off base here.
> 
> Huaiyu

Some strive to understand it by asking questions and others by trying to
find answers. 

Regards,
-- 

Pedro