[aosd-discuss] motivation for call vs execution pointcut/join point distinction

[Alexandre Vasseur]

Last time I was discussing AOP concepts with some C guy, I came
accross a suprising feeling. Why do we need to distinguish call from
execution join point in AOP implementations like AspectJ, AspectWerkz
etc. ? Wouldn't that be tied to the view we have coming from source
level / bytecode level instead of general method dispatching ?

My assumption is the following if we exclude java.lang.reflect use:
- if there is a call, there will be an execution, and nothing in
between except advices (on call first, and then on execution side
somehow - like a micro ordering)
(unless an advice hijack the flow)

So far I could spot the following motivations for a distinction

- "call" side allow to distinguish the location where the call occurs (within).
Yes but "execution" looks like a special case of that where "within"
would be "no matter what", that would have been added to the semantics
because it is somehow simpler (and more efficient) when working at
source level / bytecode level to handle it as execution pointcut as
represented in AspectJ (and thus by replication AspectWerkz and
alike).
A question is thus: if a system allows you to define (in a simple and
performant way ) "method call" event, would you need "method
execution" events and why ?

Thoughts ? I would also welcome any link or paper on that.
It is also interesting to note that AOP implementation for Java based
on C level JVMTI/DI method "event" don't make the distinction.
The discussion could perhaps be different with constructor execution
vs call as per the point where the actual instance is really
instantiated (and thus can be manipulated or precisely not
instantiated)

Alex