Re: "Humane Pointcut Languages" [Was: Re: [aspectj-users] AW:Pointcuton

["Wes" <wes@xxxxxxxxxxxxxx>]

> > The fragile nature of
> > pointcuts that refer to specific details is an example of breaking 
> the
> > Dependency Inversion Principle (DIP) and the Stable Dependencies
> > Principle (SDP), 

Sorry, I don't get it.  Why is concretizing an abstract pointcut any 
different than concretizing an abstract class or method?  No one
expects less-abstract components to be more stable.

I think the problem is that join points might not be intended by 
the "original" programmer as such, so they have no apriori stability aside
from their history - structure and naming inferences.  (but see annotations)
Nothing in a pointcut language can make up for a shifting join point model;
indirection only displaces the work (though sometimes usefully back to
to shifting programmer).

As for more abstractions (like AO interface), I personally prefer things
the programmer says in code, so we come to agreement on semantics and
support tool chains.

Wes

> ------------Original Message------------
> From: "Jonas Bonér" <jonas@xxxxxxxxxxxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Fri, Apr-28-2006 8:24 PM
> Subject: Re: "Humane Pointcut Languages" [Was: Re: [aspectj-users] AW:Pointcuton a constructor with a custom @Annotation]
>
> On 4/28/06, Dean Wampler <deanwampler@xxxxxxxxx> wrote:
> > On 4/27/06, Jonas Bonér <jonas@xxxxxxxxxxxxxxxxxx> wrote:
> > > I think Dean captures an important problem when he writes: "it 
> bothers
> > > me that we discuss high-level concerns, say for example security, 
> then
> > > turn around and write PCDs using very low-level primitives that 
> tend
> > > to reference specific classes, methods, etc."
> >
> > By the way, I should have added the word "only": "... using only very
> > low-level..." We'll always need those low-level primitives!
> >
> > > But I can't see why a more verbose, java like syntax would be more
> > > "humane", and it for sure does not address the above stated 
> problem.
> >
> > You're right that I mixed two problems, general understandability and
> > appropriate levels of abstraction. I started with the easier problem,
> > understandability; what would be easier to read and therefore more
> > "humane"?
> >
> > > I strongly believe that the only thing that helps is to raise the
> > > abstraction level above implementation details and rely on 
> metadata.
> > >
> > > (A plus would of course be to have an optional simplified syntax 
> that
> > > supports that directly, but with a goal to be more concise not
> > > verbose.)
> > >
> > > See my post 
> http://jonasboner.com/2006/04/24/domain-driven-pointcut-design/,
> > > where I actually discussing another issue, but that is closely 
> related
> > > to what I think is the main problem with having the wrong 
> abstraction
> > > level.
> > >
> > > /Jonas
> >
> > You make several great points in this blog. Contract4J only works
> > because its pointcuts use the principles you outline in your blog;
> > reliance on metadata annotations and avoidance of specific details of
> > class names, etc.
> 
> I would have liked to hear you talk at AOSD, will read the article.
> 
> >
> > I think the next major step for us is to further develop the concept
> > of interfaces in AOD, which will take us beyond the limitations of
> > what metadata annotations can provide, while still allowing us to
> > exploit the wonderful power of PCD languages like AspectJ's, without
> > some of the drawbacks.
> >
> > Finally, I would like to emphasize a point that doesn't get enough
> > attention IMHO. The problems we're facing with pointcuts are really
> > examples of well-understood OOD principles. The fragile nature of
> > pointcuts that refer to specific details is an example of breaking 
> the
> > Dependency Inversion Principle (DIP) and the Stable Dependencies
> > Principle (SDP), as described by Robert Martin
> > (objectmentor.com/resources/articles/dip.pdf and
> > objectmentor.com/resources/articles/stability.pdf).
> 
> That is an interesting observation that I think is very true.
> Did we really think that we had to solve *new* problems? I guess that,
> still "nothing is new under the sun", and that we are still "standing
> on the shoulders of giants"... ;-)
> 
> >
> > Dean
> > http://www.aspectprogramming.com
> > http://www.newaspects.com
> > http://www.contract4j.org
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> 
> 
> --
> Jonas Bonér
> Terracotta, Inc.
> 
> http://jonasboner.com
> http://www.terracottatech.com
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> 
>