Re: Perobject association (was: [aspectj-dev] pertypewithin() vs. pertyp

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

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
> > the option to inherit this instantiation model. Same again for
> > pertarget, pertype.
> >
> > Does this make sense?
> >
> > Eric
> >
> > - --
> > Eric Bodden
> > Chair I2 for Programming Languages and Program Analysis
> > RWTH Aachen University
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGP 8.0.3
> >
> > iQA/AwUBQfp66swiFCm7RlWCEQKhiwCfd08TMLxbQ2WozaW+Nil8RcvcoWoAoMPU
> > XSshRoN5eBnOig6qHEb4XNJC
> > =3woV
> > -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> > aspectj-dev mailing list
> > aspectj-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-dev
> >
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>