Re: Re: [aspectwerkz-user] proposed syntax: within construct, feedback wanted

To support "explicit syntax in expression" or inlined expression (call it as
you wish), the jjtree grammar would *ideally* have to be aware of the
potential Class expression grammar.
And more generally of the whole pointcut grammar.

It is planned to replace the pointcut pattern string parsing with a true
grammar, but there is no schedule for it.

For a temporary fix we can do a guess on "within foo.*" in the visitor algo
to check for "." (dot) or "*" (star) and then assume it is an inlined Class
pattern.
Then there is an issue with
foo.Bar - can pointcut have dot in there name ?
Bar (root package) - try to first lookup for a registered expression and if
not found assume it is an inlined Class pattern (mhh, can be dangerous, but
this is a rare use case).

Does this fix looks suitable ?

(yes I ll copy paste in Jira)
Alex


----- Original Message -----
From: "Jonas Bonér" <jonas_boner-/[email protected]>
To: "Alex" <alex-he/e8N7AIe/[email protected]>; <[email protected]>
Cc: <[email protected]>
Sent: Friday, January 09, 2004 9:26 AM
Subject: [aspectwerkz-devel] Re: [aspectwerkz-user] proposed syntax: within
construct, feedback wanted


> Redirecting to devel ML.
>
> This is a great idea, Alex. I like it a lot.
>
> Using this approach we could even write it like this:
>
>      /**
>       * @Execution int *..*.get*() within foo.bar..* and not within
foo.bee..*
>       */
>      Pointcut withinFooBar;
>
> E.g. explicitly.
>
> Good, let's settle for 'Filter' instead of 'Pointcut'.
> I prefer the 'not within' instead of the 'outside'.
> I do believe that it should be a weave time filtering.
>
> Care to put your ideas in JIRA?
>
> /Jonas
>
> --- Alex <alex-he/e8N7AIe/[email protected]> wrote:
> > Why use the && operator ?
> > My new jjtree based impl should allow to easily add the "within"
operator
> > (and even "outside" if someone needs it or may be better "not within X"
=
> > "within( not (X) )".
> >
> > Within will support nested And and nested Or (and not And / not Or) to
> > represent union and intersection [see sample below])
> > Note also that we might have to solve:
> >     (pc within X) or (pc2 within Y)
> > differently from
> >     pc within X or within Y = pc within (X or Y)
> >
> > +1 for using a Filter type field in the aspect, so that we avoid
confusion
> > with a sort of Class pointcut. But... no way to reuse it as a Class
pointcut
> > then...
> >
> > Question: should the within / outside construct be taken into account at
> > weave time or at joinpoint evaluation time ?
> > Its more natural to have it at weave time, to fit a finer grained
> > "transformation scope include / exclude", but it might add more dynamic
> > feature at evaluation time (for the cost of an overhead in out of scoped
> > classes). To be in sync with AJ it seems to be weave time.
> >
> > Alex
> >
> > [taken from Jonas' jira sample ]
> > ...
> >
> >     /**
> >      * @Within foo.bar.*
> >      */
> >     Filter withinFooBar;
> >
> >     /**
> >      * @Within foo.bar.bee.*
> >      */
> >     Filter withinFooBarBee;
> >
> >    /** @Filter special.*    */
> >    Filter x;
> >
> > And then use it to filter on class level in the other pointcut
expressions:
> >
> >     /**
> >      * @Execution int *..*.get*() within (withinFooBar && !
withinFooBarBee)
> > and not within (x)
> >      */
> >     Pointcut withinFooBar;
> >
> >
> > ----- Original Message -----
> > From: "Jonas Bonér" <jonas_boner-/[email protected]>
> > To: "Craig Fleming" <[email protected]>;
> > <aspectwerkz-user-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org>
> > Sent: Thursday, January 08, 2004 6:36 PM
> > Subject: [aspectwerkz-user] proposed syntax: within construct, feedback
> > wanted
> >
> >
> > > Hi guys.
> > >
> > > I have sketched some on how to support the within construct. Feedback
> > please.
> > >
> > > http://jira.codehaus.org/secure/ViewIssue.jspa?key=AW-119
> > >
> > > /Jonas
> > >
> > > --- Craig Fleming <[email protected]> wrote:
> > > > On Thu, 8 Jan 2004 00:24:03 -0800 (PST), Jonas "Bonér"
> > > > <jonas_boner-/[email protected]> wrote:
> > > >
> > > >
> > > > >> 1. I'm trying to use the subtype wildcard on return types.
> > > > >> @Execution Object *..*.*(..) - works, but isn't what I want
> > > > >> @Execution Object+ *..*.*(..) - doesn't pick out anything
> > > > >This is a current limitation in AW. I understand that there is a
need
> > for this and will add it
> > > > as
> > > > >soon as I get the time.
> > > >
> > > > Cool. A not so efficient way of getting around it is to use
> > > > @Execution * *..*.*(..)
> > > > And then filter by MethodJoinPoint.getReturnType().isPrimitive().
> > > > Naturally it would be more efficient if this could be filtered out
> > > > sooner than inside the advice itself, but this works nicely.
> > > >
> > > > >You can add within's that is global to the aspect system usint
> > 'transformation scopes':
> > > >
> >
>http://aspectwerkz.codehaus.org/definition_issues.html#Transformation%20sco
> > pes
> > > > >
> > > > >If there is a high need for it I guess that it would not be a
problem
> > to make this feature more
> > > > >fine-grained.
> > > >
> > > > May be another feature to add to that ever-extending list of yours,
> > > > but in my particular case the transformation scopes are exactly what
I
> > > > needed.
> > > >
> > > > >It is not possible to advise advices (or aspects). This is a design
> > choice and could of course
> > > > be
> > > > >discussed. But my belief is that it adds more problems than it
solves.
> > > > >
> > > > >cflow support was just recently committed to the CVS (couple of
days
> > ago), it is not supported
> > > > in
> > > > >the RC. If you need cflow support before the final 0.9 is released
you
> > have to use CVS HEAD.
> > > >
> > > > I was just wondering if I needed to filter out my aspect code, as in
> > > > AspectJ if you don't, you end up with bigger runtime than you
actually
> > > > wanted. I am a believer in making the system as flexible as
possible,
> > > > and then letting the programmer make his or her own decisions.
> > > > Naturally I'm a Java programmer, and not a C++ programmer (more
> > > > flexible, but so much more ...ugly), so I don't always stick to
this,
> > > > but I can't count the number of personal projects where I've been
> > > > thwarted by a final class or private variable. ;)
> > > >
> > > > Don't add this one to your list, I'm not making an argument for it.
:)
> > > >
> > > > Thanks,
> > > > Craig
> > > >
> > > > _______________________________________________
> > > > aspectwerkz-user mailing list
> > > > aspectwerkz-user-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> > > > http://lists.codehaus.org/mailman/listinfo/aspectwerkz-user
> > >
> > >
> > > =====
> > > Jonas
> > > http://blogs.codehaus.org/people/jboner/
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> > > http://hotjobs.sweepstakes.yahoo.com/signingbonus
> > > _______________________________________________
> > > aspectwerkz-user mailing list
> > > aspectwerkz-user-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> > > http://lists.codehaus.org/mailman/listinfo/aspectwerkz-user
> > >
> > >
> >
> > _______________________________________________
> > aspectwerkz-user mailing list
> > aspectwerkz-user-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> > http://lists.codehaus.org/mailman/listinfo/aspectwerkz-user
>
>
> =====
> Jonas
> http://blogs.codehaus.org/people/jboner/
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
> _______________________________________________
> aspectwerkz-devel mailing list
> aspectwerkz-devel-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> http://lists.codehaus.org/mailman/listinfo/aspectwerkz-devel
>
>