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

["Gregor Kiczales" <gregor@xxxxxxxxx>]

I certainly agree that it's a problem with AspectJ that only the pointcut
language is compostional and supports abstraction.

In that sense the type pattern and signature sub-languages aren't real
languages.
As I recall we once flirted with fixing this, but I think the solutions we
were
playing with seemed too cumbersome for the problem being solved.  But it
sure would
be good if this got fixed at some point.

> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx 
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> Sent: Thursday, April 20, 2006 8:03 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: "Humane Pointcut Languages" [Was: 
> Re:[aspectj-users]AW:Pointcuton a constructor with a custom 
> @Annotation]
> 
> I agree that having a concise pointcut language is helpful, 
> and most pointcuts can and should be fairly simple to read 
> (just as with XSLT!).
> However, when you start building up expressions with 
> annotation patterns or with proposed type patterns for 
> matching interface, final modifiers, etc., it can get hairy.
> 
> I think having the ability to name type patterns and 
> signature patterns and to compose them would be very helpful. 
> This is rather akin to C/C++ where typedef made it much 
> easier to build up readable expressions like pointer to 
> reference to array of functions. I think having named 
> patterns like this would also improve modularity for 
> pointcuts that match more than one of call, execution, 
> withincode at a signature. Typedefs would also restore the 
> ability to match a pattern of types you don't control 
> (whereas in AspectJ 1.1+, you have to be able to use declare 
> parents or declare annotation to pick these out)...
> 
> Ron
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of 
> Gregor Kiczales
> Sent: Thursday, April 20, 2006 4:20 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: "Humane Pointcut Languages" [Was: Re:
> [aspectj-users]AW:Pointcuton a constructor with a custom @Annotation]
> 
> Hmmm...
> 
> Reminds me of http://www.charlespetzold.com/etc/CSAML.html 
> 
> More productively, I think the concision of the pointcut 
> language is a plus; but I can imagine some nice tool support 
> that you could hover the mouse over and see an elaboration of 
> the pointcut.
> 
> > -----Original Message-----
> > From: aspectj-users-bounces@xxxxxxxxxxx 
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> > Sent: Thursday, April 20, 2006 2:46 PM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: RE: "Humane Pointcut Languages" [Was: Re: 
> > [aspectj-users] AW:Pointcuton a constructor with a custom 
> @Annotation]
> > 
> > I agree completely. I've often said that AspectJ's 
> pointcuts and type 
> > patterns need a long form, rather like xpath has a long, functional 
> > style one in addition to its dense, compact, and cryptic version, 
> > e.g., //title is short for 
> > /self::node()/descendant-or-self::node()/child::title (in a simple 
> > case, the short form is clearer, unsurprisingly!)
> > 
> > I could see a more functional non-positional syntax, e.g.,
> > 
> > signature annotatedConstructor : member-annotation(@MyAnnotation) &&
> > static-type(*) && method-name(new) && static-arguments(..);
> > 
> > pointcut callAnnotated() : call(annotatedConstructor);
> > 
> > -----Original Message-----
> > From: aspectj-users-bounces@xxxxxxxxxxx 
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Dean Wampler
> > Sent: Thursday, April 20, 2006 2:04 PM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: "Humane Pointcut Languages" [Was: Re: [aspectj-users] AW:
> > Pointcuton a constructor with a custom @Annotation]
> > 
> > Ron Bodkin wrote:
> > > Dean, I think you mean call( @MyAnnotation *.new(..) ) (or just 
> > > call(@MyAnnotation new(..))), since there's no return type for a 
> > > constructor.
> > > ...
> > >   
> > Yes, I forgot about the extra "*" for the (invalid) return 
> type that 
> > was in the expression. Need to get my glasses checked, I guess ;)
> > 
> > I've made mistakes like this occasionally in my own PC definitions 
> > (PCDs). The PCD language is very "dense" and requires careful 
> > inspection of any PC. Given a lot of recent discussion in the 
> > bloggosphere about "humane interfaces"
> > (e.g.,
> > http://www.martinfowler.com/bliki/HumaneInterface.html), it 
> would be 
> > interesting to consider a more verbose & humane PC language for 
> > AspectJ that could be used with the existing language. When you 
> > consider that a typical PCD, like most code, is written once and 
> > potential read many times, I would certainly use a more verbose 
> > language if it were available.
> > 
> > For example, Perl has more human-readable equivalents to its many 
> > cryptic "$..." variables. What if AspectJ's PC language had special 
> > symbols like the following:
> > 
> > $any_return       => "*" used for the return type
> > $any_arg           => "*" for any single method argument
> > $any_arglist       => ".."
> > 
> > etc.
> > 
> > Just a thought...
> > 
> > dean
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > 
> > 
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > 
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>