About aspects

by Simon Hudon (modified: 2019 Sep 18)

I just watched the Aspect Oriented Programming presentation that Martin Seiler posted recently and I remembered how interested I was about this new paradigm a year ago. Then, I look at it again and wonder what its true value is. One of the major attacks against it is that it violates the locality of the code meaning that you can no longer (or, in fact, less than before) reason about a routine to convince yourself of (or prove) its validity: you also have to take the context into consideration (meaning the set of aspects in the system).

Furthermore, it seems that most of the experimentations has been conducted on languages like java which lack multiple inheritance. Would it only patch this lack of expressive power? For example, if we analyze the observer pattern presented in the video, we can see that an easy way to do it would be like this:

class POINT feature -- Access x: REAL_64 assign set_x y: REAL_64 assign set_y feature -- Element change set_x (new_x: REAL_64) is -- set the x coordinate do x := new_x end set_y (new_y: REAL_64) is do y := new_y end end class OBSERVABLE feature -- Element change add_observer (o: OBSERVER) is do if not observers.has (o) then observers.extend (o) end end prune_observer (o: OBSERVER) is do observer.prune (o) end feature {NONE} -- Implementation observers: LIST [OBSERVERS] notify_observers is do observers.do_all (agent {OBSERVERS}.react_to_change_of (Current)) end end class OBSERVABLE_POINT inherit OBSERVABLE POINT redefine set_x, set_y end feature -- Element change set_x (new_x: REAL_64) is do Precursor (new_x) notify_observers end set_y (new_y: REAL_64) is do Precursor (new_y) notify_observers end end

Of course, in the context of a MVC system, the granularity of this seems a little strong compared to event object but it think we can find an analogy with the advice and pointcut ideas: the redefinition of set_x and set_y define the pointcut and the notify_observers would be the advice. The main advantage here is that if we put contracts too strong to allow this redefinition, we can see that the error is in the redefinition: because the specification is too restrictive, it would not be too complicated to see that applying an advice is impossible.

One may object that we cannot specify a pattern to match the join points. This idea appears a little hazardous to me since there can remain errors that a simple symbol lookup would find but since it's only a textual pattern matching, no validity test can be performed.

I'd like to hear the opinion of other Eiffelists,

Cheers!

Simon

On aspects: Martin Seiler, "No more boring TV"

Comments
  • Julian Tschannen (17 years ago 5/6/2007)

    aspects

    I don't think that the argument of code locality counts: That's the job of the IDE. If your IDE can show you where and which aspects are integrated then you can reason in the same manner about a program as now. It's the same with features now. If you need to check all inherited contracts this is a tedious task manually, but due to EiffelStudio it's a simple click. The same goes with the contract, comment and the implementation of any called feature. Just knowing the name of the feature is not enough, so you are going to use an IDE to see the full interface of it.

    One of the first examples you always hear with aspects is logging. If you want to log a number of feature calls, an implementation like yours for the observer pattern is not possible anymore. Actually any aspect which would go over multiple classes would not work with multiple inheritance. The other problem is that an implementation with inheritance works only if you can use the new class. If you want to change the behaviour of existing classes (be it for logging or to make a library observable which wasnt before) then the ineheritance approach doesn't work. Say you now make you OBSERVABLE_POINT class. Then an existing algorithm which calculates an intersection between a line and a plane still gives you a normal POINT object which is not observable.

    So I'm in favor of investigating aspect-oriented programming more and see if it gives more benefits than just the standard examples like logging. Some uses of aspects for Java may not be necessary in Eiffel since the language itself gives us more possibilities like multiple inheritance and contracts, but on the other hand aspects for Eiffel may also profit from this and could be able to do more than aspects for Java.

    • Simon Hudon (17 years ago 5/6/2007)

      aspects

      One question would remain: would you still have to prove every routine or advice every time you reuse them? For example, if you pull an aspect or several aspects from one library and many classes from another one, would you have to go again through a whole V&V process instead trusting the formal proofs or intensive testing the component provider made? One thing that could help is to impose constraint on reusable aspects. For example, we could have a principle that goes:

      Do not put aspects with effective pointcuts in libraries.

      That would only leave deferred pointcuts (or abstract in AspectJ-speech). Those are pointcuts on which advices can apply but must be defined in descendant aspects. This makes reference to the fact that, in AspectJ, aspects can inherit from a single abstract aspect. Maybe this would be overkill too. If we dispose of a more deterministic pointcut model, maybe we would still be able to rely on component provider trust. I think one such model would not rely on pattern matching to find joinpoints, in particular because of renaming and refactoring. With such a pointcut model, we would still be able to address the problem of a point created by some algorithm.

      To conclude, I want to note that I find aspect programming very interresting and hope this blog post will not be taken as an attempt to discredit the idea but rather as an attempt to provoke discussion to find what benefit it could give in the Eiffel methodology. Also, I agree with you, Julian, it would be interresting to see something more than logging to support the idea.