[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspectj-dev] pertypewithin() vs. pertype() association...
- From: Eric Bodden <eric@xxxxxxxxx>
- Date: Tue, 25 Jan 2005 18:46:05 +0100
- Delivered-to: email@example.com
----- Original Message -----
From: "Adrian Colyer" <adrian_colyer@xxxxxxxxxx>
> You make a good case for the pros of the PointcutDesignator form. The
> design as documented (and mostly implemented in the tree) was a compromise
> between the (A) and (B) designs in the bug report.
> I'd like to hear the opinions of others on this point too, so please jump
> in if you have an opinion one way or the other...
Well, since you asked for it...
I certainly would not very much go for option (B), which would allow *any*
pointcut in a pertype-clause if I understood correctly. The problem arises
for me, as soon as people start reasoning about expressions like
pertype(call(* Foo.bar())). It's not quite straightforward here, what type
is meant: Do we get an instance for the calling type or the caller type - or
maybe even for both.
From the simplicity point of view, my personal opinion is that
pertypewithin(<TypePattern>) would be best. The major drawback as you
mentioned turns out to be "sub-aspecting". But if it was possible to have
subclasses define their own pertype-instantiation, I guess that would be a
Another question I had in mind was if you also considered *perobject*
instantiation rather than pertype, as proposed in the "association aspects"
paper (http://portal.acm.org/citation.cfm?id=976275). I have actually found
quite some use cases where you want to associate aspect instances with a
certain object which is *not* necessarily exposed through a given pointcut.
One such use case is for example where you want to track the state of a
certain object in order to perform validation on it or something similar.
percflow/perthis/pertarget sometimes turn out to be "too weak" for this.
Hope that helps,
RWTH Aachen University