Re: [abc-dev] the Join operator extension for AspectJ

From: Ganesh Sittampalam <ganesh@earth.li>
Date: Fri Mar 11 2005 - 22:17:45 GMT

Hi,

[replying on abc-dev as that's the most appropriate list for this]

On Fri, 11 Mar 2005, Gunny Lee wrote:

> I would like to add a new operator to the AspectJ compiler, called
> join. However, I was told that one of you guys were already working on
> an operator very much like this one, and I'd like to touch base with
> that person.

Unfortunately this isn't the case. While a join operator has been
occasionally discussed by other people, it has very different behaviour to
the one you describe below and in any case we have no current plans to
implement it.

> The purpose of the join operator would be to take two aspects and
> (surprise) join them as one. For example, consider you have an aspect
> where after A.foo() has been called, it makes a call to the logger
> (basically as an after advice). Now say you have another aspect where
> after A.bar() has been called, it makes the same call to the logger.
> Suppose you want to combine these two aspects (it may be easier to
> think of them as services), and say you want to make the call to the
> logger only after *both* A.foo() and A.bar() has been called. This is
> what the join operator would do.

This is a rather ambiguous definition. How would join decide that two
pieces of advice should be joined? Based on them having identical bodies?
This strikes me as rather fragile, though. Similarly, when precisely would
the combined advice match? Would the calls to foo and bar have to be in
the same method? How many times would it match if foo was called once then
bar was called several times? etc etc.

> So if indeed this is being worked on already and you know who, please
> let me know. I'd be very interested in the implementation (if it is
> complete) or otherwise helping with the development efforts.

As I said, there's no current development effort, but if you're interested
in extending abc we'd be happy to provide advice where we can. I'd suggest
that the first step should be to develop a precise definition.

Cheers,

Ganesh
Received on Fri Mar 11 22:17:54 2005

This archive was generated by hypermail 2.1.8 : Fri Mar 11 2005 - 22:40:06 GMT