Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Philosophical Questions

Hi,

Here are my thoughts about AOP.

2) Can pointcuts be modeled separately from advice?

I think about pointcuts with like a special kind of operations that can be invoked by the system itself when certain conditions are met. These conditions (the jointpoints) and their context (caller object, parameters ...) are part of the signature of the pointcut.
I see the advice as executable code that is associated with a pointcut. In regular OOP you have abstract operations, with signature but without code, and concrete methods (implementations of that operations).
So I think that in AOP abstract pointcuts (without advice) are the equivalent of abstract operations and advice are the concrete methods.
Of course advice without a pointcut have no sense in the same way that a piece of code have no sense without an operation with his signature. But it is usefull to have this separation because you could have different advices for the same pointcut (like polymorphic methods in OOP).

To sum up, separation pointcut/advice? yes. Full independence? no, the advice must always run in the context of a pointcut.

1) Can Aspects themselves be broken down into smaller sub-components?


In this way of thinking you should want to separate the definitions of the pointcuts from the advices associated with them, like you want to separate the abstract operations in an interface and the implementations of the operations in a class.
If I have different advice that correspond to the same pointcut I would like to decide what advices are active and what not. This decision could be made at compile, load or run time.  For load time it could be usefull define in a separate file what advices (and/or pointcuts) activate.

So, if I want a full flexible functionality I'd like broke aspects into smaller subcomponents, but if not it is overwhelming to make these separations. My ideal is that the language allow me to decide what level of separation I want to use.

3) What role, if any, should metadata play in AOP?

I am confused about the use of metadata in AOP. I can understand the generation at compile time (or by descriptors) of metadata in order to achieve more performance (or an easier implementation) in the real AOP languages/frameworks. But I don't know if people intend to use metadata in another way. Really I'm confused about this point.

Hope more people reply to this thread. I'm really interested in the opinion of others.


Enrique J. Amodeo Rubio


Merrick Schincariol wrote:
Philosophical Questions

Having just got back from TheServerSide Symposium in Boston, I can report that AOP was definitely the talk of the conference. What was surprising to me, however, was the lack of focus on AspectJ. Most comments were of the form "it's too powerful for most developers" or that the special compiler makes it difficult to sell in most organizations. Instead, most of the talks focused on newer "pure Java" AOP frameworks.

I personally find AspectJ to be a well designed implementation of AOP concepts. On my weblog (http://www.freeroller.net/page/mschinc), I've been documenting my own exploration of the capabilities that AspectJ provides. Looking closer at "pure Java" approaches like AspectWerkz (http://aspectwerkz.codehaus.org/) something has been bothering me, but I haven't been able to put my finger on it. I'd like to put a couple of questions out to the list and see where your thoughts are on the subject.

1) Can Aspects themselves be broken down into smaller sub-components?

Most of the Java AOP frameworks break out aspects into a number of different pieces. For example, you implement your advice as one Java class, your introductions as another and then define (usually using XML) the pointcuts and the relationships between the components. So one Aspect could actually require many files to implement and define. Does the complexity of this approach interfere with the AOP philosophy? My fear is that when the implementation requirements are complex, from a language point of view, you start to lose track of the problem you are actually trying to solve.

As an aside, I think the AspectWerkz design for advice is broken. Because each type of advice is a class (pre, post and around) and each advice class extends a pre-existing class, you can't share any information between different types of advice on the same pointcut.

2) Can pointcuts be modeled separately from advice?

This follows on the above point, but it's one that I find a little odd. Most (all?) of the pure Java approaches define their pointcuts in one file and their advice in another. Presumably this means that advice can be reused across multiple different aspect definitions. From a philosophical point of view, can advice be modeled truly independently from pointcuts? I would think that certain types of advice, particularly when dealing with cflow and other advanced join points, really require the pointcut definition to be present in order to make sense.

3) What role, if any, should metadata play in AOP?

I know Gregor has commented on the use of metadata a couple of times, but the JBoss group is charging ahead with their "AOP" product which encourages developers to use class metadata to load library aspects. This strikes me as wrong in many ways, but the message that is reaching the development community is that interceptors and metadata are all you need to do AOP. Is this just a function of what's easy to implement, or are people really having trouble grasping the concepts?

I'm looking forward to hearing your thoughts.

Cheers,

Merrick



Back to the top