Hooks, aspect-oriented programming, and design by contract

[Pedro Rodriguez]

"Luigi Ballabio" <ballabio at mac.com> wrote:


> Hi,
> 	maybe I'm just reinventing the wheel, but I just noted that Alex's
> Aspecter function can easily be twitched to enforce some kind of design
> by contract (which of course can be considered an aspect). Here's my
> first shot at it. Corrections and improvements are much welcome.
> 
<sample code snipped>

Technically, the same method is used to achieve the result. But I don't
know if this is the same thing.

Your predicate/invariant is a property of the class and should be applied
to all methods and attribute setting (BTW : I wonder how this later case
can be checked with the use of properties).

In your example, private helper methods may temporarly render the state of
the object invalid, these shouldn't be wrapped I think (checking that the
method name don't start with '_' for example ?).

As far as I understand, an 'aspect' is something that crosses several
methods in a class but not mandatory for all of them. It can also be
applied to different classes. An 'aspect' as implemented in AspectJ, or
in my implementation, may also have a state and so behave also as a class.

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.

Regards,

-- 

Pedro