[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: Perobject association (was: [aspectj-dev] pertypewithin() vs. pertype() association...)
|
I don't have time to reply to the whole thing right now, but:
<<<
P.S. - re:
> The set of join points at which the aspect can become
> disassociated with a previously associated instance
There's no such dissociation. It's Java; there's only
garbage collection! Once Foo.aspectOf(x) returns f
for x, it will always return f for x. Whether any
advice will ever run again is a whole 'nuther question.
>>>
I know. I'm saying there *should be*. There's no (fundamental) reason why
Foo.aspectOf(x) can't start returning null again after some point.
Cheers,
Nick
--- Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> Hi folks -
>
> So instead of saying
>
> aspect A perthis(pc()) {
> before(This t) : somePointcut(t) {
> ...
> }
> }
>
> perhaps I should say, for each possible type,
>
> class PerThis {
>
> Object thisObject;
>
> private PerThis(Object o) { thisObject = o; }
>
> static aspect InitPerThis {
> pointcut pc() : ...;
>
> Perthis getInitPerThis(Object o) { return o.perThis; }
>
> PerThis Object.perThis; // assuming you could...
>
> before(Object) : pc() && this(o) {
> o.perThis = new PerThis(o);
> }
> }
>
> static aspect usePerThis {
> // must use "perthis(..) && " with all advice
> pointcut perthis(Object o) : this(o) && if(null != o.perThis);
>
> before(Object o) : perthis(o) && somePointcut() {
> This t = (This) o;
> ...
> }
> }
> }
>
> Or instead of
>
> after() : pc() {...}
>
> perhaps I should say
>
> Object around() : pc() {
> try {
> return proceed();
> } finally {
> ...
> }
> }
>
> or
>
> Proxy proxy = ...
>
> I'm hearing that you can use perobject(..) to implement perthis(..)
> using lower-level facilities, and get more control. What would
> be convincing to hear about perobject(..):
>
> - It's easier to use
> - It can't be done in AspectJ today
> - There are compelling use-cases for it
>
> I agree that what's confusing about perthis(..) aspects is
> realizing that the pointcut for each advice in the aspect
> has an implicit "&& this(Type)".
>
> So where the programming guide says
>
> ------------------------------
> The advice defined in A may then run at any join point where
> the currently executing object has been associated with an
> instance of A.
> ------------------------------
>
> perhaps it should say
>
> ------------------------------
> The advice defined in A will only run at a join point ...
> ------------------------------
>
> wrt IDE's, has anyone checked whether, when AJDT lists the code
> advised by a particular piece of advice in a perthis aspect,
> it omits those outside the scope of this(Type)? Also, it might
> be nice to list, for a selected type, the per[this|target]
> aspects that might be associated with it.
>
> Wes
>
> P.S. - re:
> > The set of join points at which the aspect can become
> > disassociated with a previously associated instance
>
> There's no such dissociation. It's Java; there's only
> garbage collection! Once Foo.aspectOf(x) returns f
> for x, it will always return f for x. Whether any
> advice will ever run again is a whole 'nuther question.
>
> > ------------Original Message------------
> > From: Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>
> > To: aspectj-dev@xxxxxxxxxxx
> > Date: Fri, Jan-28-2005 12:05 PM
> > Subject: Re: Perobject association (was: [aspectj-dev] pertypewithin()
> vs. pertype() association...)
> >
> > I like your proposal! Per(target/this) aspects currently behave rather
> > oddly, because they mix the 4 concerns together. Separating them in the
>
> >
> > source would allow programmers to appreciate the four facets of
> > behavior independently. I can see some other strengths that are
> > currently missing:
> >
> > strength 1) Association becomes advice which you can see in various
> > cross-cutting views, step into more easily, etc.
> > (ok, I only thought of one)
> >
> > However, there are some strengths to the current approach that your
> > proposal does not address (and I say this only because I want to
> > improve the proposal enough to get it accepted).
> >
> > weakness 1) You could mismatch your association pointcut so that it
> > never selected objects of the appropriate type (this is probably
> > livable)
> > weakness 2) New types might match the association pointcut but not
> > match the per clause type(pattern?)
> > weakness 3) the association advice would appear in an aspect whose
> > other advice does not apply unless the aspect has already been
> > associated, meaning that the association advice would need to be
> > demarcated as "special" somehow
> >
> > Cheers,
> >
> > Nicholas Lesiecki
> > Software Craftsman, specializing in J2EE,
> > Agile Methods, and aspect-oriented programming
> > m: 520 591-1849
> >
> > Books:
> > * Mastering AspectJ: http://tinyurl.com/66vf
> > * Java Tools for Extreme Programming: http://tinyurl.com/66vt
> >
> > Articles on AspectJ:
> > * http://tinyurl.com/66vu and http://tinyurl.com/66vv
> > On Jan 28, 2005, at 10:48 AM, Eric Bodden wrote:
> >
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Nicholas Lesiecki wrote:
> > >> I've been thinking about perobject aspects in the shower and I've
> > >> decided that the current perobject aspects handle several concerns.
> > >> I think it's worth dissecting them for greater clarity of thinking:
> > >>
> > >>
> > > [...]
> > >> Ideally, the perobject aspects would give the programmer control
> > >> over all four concerns. Ok, that's all I have for now. Does anyone
> > >> want to pick up this ball and run it the next few yards?
> > >
> > > I completely agree. Also I think that perobject asoects would
> > > eventually yield a much clearer instantiation model. As Mira Mezini
> > > et al. showed in their CEASAR implementation, perobject aspects and
> > > percflow aspects actually completely suffice to implement all the
> > > instantiation models we have in AspectJ today:
> > >
> > > aspect A perthis(<Type>) {
> > >
> > > }
> > >
> > > is nothing more than:
> > >
> > > aspect perobject(<Type>) {
> > >
> > > after(<Type> t) : this(t) {
> > > associate(t);
> > > }
> > >
> > > }
> > >
> > > Same counts for pertarget *and* the newly proposed pertype as well,
> > > given that "pertype" actually means not more than "perobject", the
> > > "object" being the metaclass <Type>.class for any newly initialized
> > > type.
> > >
> > > Thus in the one could even completely loose perthis, pertarget,
> > > pertype, ... (not percflow, that'S really different), since they
> > > actually all are just special cases of object-associated aspects! In
> > > my personal opinion that would be much clearer than today. You can
> > > associate aspects with a set of objects or with a control flow. Not
> > > more.
> > >
> > > If one still wants for the sake of brevity a "perthis" aspect, one
> > > could probably find a means of inheriting instantiation advice (as
> > > above) down to subaspect types in a well-defined way. So you could
> > > have a PerThis super-aspect as above and all subaspects *may* have
>
=== message truncated ===
