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

What's wrong with the && operator? What's better about using 'and' and
'or'? Personally, from years of programming I find &&, || more
readable.

Also there is precedence for having a Pointcut that is not actually a
pointcut. AspectJ uses args(), target(), this() in multiple contexts.
Obviously this isn't to be taken as "Do it this way because AspectJ is
always right." but I figured I'd point it out. :)

Craig

On Fri, 9 Jan 2004 00:26:52 -0800 (PST), Jonas "Bonér"
<jonas_boner-/[email protected]> wrote:

>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