Re: [aspectj-users] parameter evaluation and advice

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

Hi -

> to do this you need a fully dynamic system with proper macro support

I'm not sure that's true.  In AOP, you'd just need a join point
that included the parameter evaluation.  This would be possible
in a source-based implementation, but it would be hard in
bytecode to recognize the affected code.  Similar considerations
go into supporting a join point for something like this:

    field = (Something) else();

where you'd like to grab the assignment, cast, and method-call.

The question is whether these are useful and principled join points.
I'd be interested in a definition of "principled", but it at least
includes the following properties:

- a unit the average programmer recognizes
- easily and meaningfully addressable by pointcut designators
- implementable: different implementation strategies
  can detect and close over the join point with
  reasonable effort

E.g., a possible join point not in AspectJ 1.1 is for "throws".

While AOP has roots in dynamic languages, it has really come alive
in Java because AspectJ can encapsulate crosscutting concerns
without introducing the complexity and indeterminacy of
dynamic languages or generative approaches.

Wes

Lendvai Attila wrote:
> :: Consider the following advice:
> :: 
> ::     void around(Logger aLog) :
> ::         call(public * Logger.debug(..))
> ::         && target(aLog)  {
> ::             if (aLog.isDebugEnabled()) {
> ::                 proceed(aLog);
> ::             } 
> ::         }
> :: 
> :: This advice works as expected - it prevents calls to 
> :: log.debug(myString) from executing if log is not debugEnabled.  
> :: 
> :: However, testing for a side effect on myString or examining 
> :: byte code reveals that the parameter to the debug() method 
> :: ('myString') is being evaluated, even if log is not debugEnabled and
> :: proceed() is never called.
> :: 
> :: I'm not familiar with how AspectJ is implemented, but... is 
> :: there a way to prevent parameter evaluation in this example?  
>
> to do this you need a fully dynamic system with proper macro support (a
> system/language where code = data is practically true, and has runtime
> eval/compile). if you are willing to invest in learning more about the
> possibilities you can find a lot of good reading at
> http://cliki.tunes.org/index the Learning Lounge section contains a
> structured info that you can read/skip base don your knowledge.
>
> i don't say that it couldn't be done by the brilliant aspectj team, but
> it would mean partially implementing such a dynamic system (?). i would
> be more than happy to see macros/eval/compile in java, but there's
> little probability of that.
>
> <dreaming>
>
> oh, well. if only java were not bootstrapped by a VM written in a
> different language, but instead a fully self contained system that has
> code as first class objects and can generate executables for different
> platforms by it's compiler written in itself. but that would be a
> different story, a different language...
>
> </dreaming>
>
> 101
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users