aspects

maverick — Tue, 05 Jun 2007 04:51:34 -0700

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.

aspects

juliant — Mon, 04 Jun 2007 19:45:00 -0700

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.

eiffelroom - aspect programming - Comments

aspects

aspects