Re: [aspectj-users] Philosophical Questions

["Enrique J. Amodeo Rubio" <eamodeorubio@xxxxxxxxxxxxxx>]

I'll try to explain myself more accurately.

public aspect ExampleAspect { 
...
	before() : pointcut goes here { 
	... // Advice body here 
}
...
}

Although this is not bad coding style, it is equivalent (in a
functional way) to:

public aspect ExampleAspect { 

pointcut mypointcut(): pointcut goes here;
...
	before() : mypointcut() { 
	... // Advice body here 
}
...
}

So you can consider 	before() : mypointcut() as the "context" under
the advice body is executed. The idea is that you can have associated
various piece of code to this "context"  (in my previous e-mail I
called it signature). Then you can decide what of this implementations
want to use at compile time (perhaps at load time or runtime too). 

My point is that pointcuts (named or anonymous) are an extension of the
signature of regular methods in OOP. Regular methods are called by
other methods, "AOP methods" (pointcuts with advice) are called when
the joinpoints of  the pointcut are reached. In some papers they are
named "callback methods". So in an AOP language we have regular methods
and callback methods. 

In my last e-mail I tried to make a paralellism with interfaces and
classes in OOP. When I said "abstract" pointcut I mean a pointcut
without advice associated, it's abstract in the OOP way. Not the same
that abstract pointcuts in AspectJ, they are abstract in that they not
have associated jointpoints. So "abstract" is in the OOP way and
abstract in the AspectJ way. 

My intent was to indentify a starting set of good practices in AOP
using this paralellism with OOP. If in OOP separation between
interfaces and implementation (classes) have been demonstrated good by
the experience, in AOP separation between "abstract" aspects and
"concrete" aspects could be good. Other example: In Java, dynamic class
loading is very usefull. This and the use of interfaces allow the
development of an application that admit plugins. So in AOP a mechanism
of dynamic deployment of "concrete" aspects (that should conform to an
"abstract" aspect) could be interesting. Both of them are good
candidates to investigate, and I think they can currently have an
elegant (and type-safe) implementation with AspectJ.

Of course in AspectJ you can have abstract pointcuts without any
jointpoint defined. And you can attach an advice to an abstract
pointcut. It is a flexible mechanism. But you can specify some
"context" for the advice too. Think in: pointcut abstract
p(IMyInterface o);. You don't define when the pieces of advice will be
invoked, but you force that they will have avalaible an object of  type
IMyInterface. Clearly this has no direct paralelism with OOP. AOP add a
new dimension to OOP, the jointpoints. In this case we played with this
new dimension, making an advice abstract in the joinpoint dimension, so
it have no counterpart in OOP. This lead to more advanced topics
(someone knows how to implement in AspectJ?):

    a) Late definition of a pointcut. Decide at load or runtime what
set of jointpoints have a pointcut. A mechanism to do it in a type-safe
way could be very powerful.
    b) Introspection of aspects and pointcuts. Related with a).

Of course for many applications this level of complexity is not needed,
so don't use it. It is the programmer who must keep his system as
simple as possible, but the language must be enough powerful to allow
build a high flexible and manteinable system when is needed.

I feel that aspectJ should have constructs to separate and manage these
dimensions (advices, jointpoints and context) without merging concepts.
It could be interesting a "pointcutinterface" (a collection of public
abstract pointcuts),  a  "pointcutclass" that complete the jointpoints
of several "pointcutinterfaces" and aspects (which associates advices
to "pointcutinterfaces" and decide which "pointcutclass" activate and
desactivate). But these are ideas for the future that need more
discussion (perhaps they are too complex, inefficient of implement, or
of no use ! ). For now it's enough to have a stable an efficient
implementation of the AspectJ language and compiler. 

It's my opinion that AspectJ should have constructs that allow the easy
(and meaningful) implementations of idioms and patterns the community
thinks are useful. In the same way it's important to declare
"deprecated" those language constructs that community thinks lead to
bad design. We do not should only extend the language but to clean it.

I hope you have more to say about all of this. 

Cheers,

    Enrique J. Amodeo

P.S. 
I have (superficially) seen AOP frameworks and I consider them easy but
simple. I have no performed stress test on them (and cannot found
reports on it, perhaps JBoss team have some). And I consider (and have
suffered in J2EE) that XML descriptors without tool support lead to
chaos in big projects.

Can anybody explain all this stuff about tags? Why I need tags when I
have language constructs?  I don't like the idea of looking for places
to add tags in old code (potential thousands of classes). It's too
similar to adding event support to old code. Aspects must be
transparent composable. Perhaps I missed the point behind tags.




Alon Amsel wrote:
> >  
> >     
> > 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. 
> >     
>   
> I think these issues are different. Especially if you model something
> that is/will be implemented in AspectJ, you have to consider the
> possibility that pointcuts are not defined explicitly. What I mean is
> you can write an aspect like this: 
>   
> public aspect ExampleAspect { 
>   
> 	before() : pointcut goes here { 
> 	... 
>   
> If the pointcut can be defined within 1 line of code, this is not even
> considered bad coding (or is it?) 
> Obviously, the pointcut is still there, but unlike with an OOP method
> signature, you are not forced to declare the pointcut after a 'pointcut'
> keyword. 
> Therefore, IMHO, it would be an overkill to model something that
> doesn't even appear in the code. I am thinking about a hierarchical AOP
> model where all the pointcuts (explicit or implicit) would fit in a
> lower level of abstraction, while at the highest level, implicit
> pointcuts would (in the best case) be represented by (for instance)
> UML-like relations... (or something like that). 
> I also think advice is more than just the implementation of an aspect.
> At the design level (whatever that is), we don't need the
> implementation, we just need to know 'what a piece of advice does'.
> Again, in a hierarchical aspect model, it should be possible to model
> more detail as we drop a level of abstraction. 
>   
>   
> > 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. 
> >     
>   
> I hope getting some feedback about this too. 
> Cheers, 
>   
> Alon 
> >  
> >