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

Oooh. Ok. Let me make sure I got it right:

/**
 * @Execution foo.*(..)
*/
Pointcut executionPointcut;

/**
 * @Around executionPointcut && foo.*
*/

Was what you were objecting to, and

/**
 * @Within foo.*
*/
Filter fooFilter;	 (or Pointcut)

/**
 * @Around executionPointcut && fooFilter
*/

Is what you were arguing for? I agree. :)

Craig

On Fri, 9 Jan 2004 20:41:14 +0100, "Alex"
<alex-he/e8N7AIe/[email protected]> wrote:

>Craig
>
>the && will off course be maintained as well as || and !
>and , or , not are just synonyms
>as well as AND OR NOT
>
>I was arguing that "and" (&& / and / AND) is not suitable to express a
>"within" concept. It is better to use "within / WITHIN" since the new
>implementation (in cvs head) allows this.
>[see http://blogs.codehaus.org/people/avasseur ]
>
>Alex
>
>----- Original Message -----
>From: "Craig Fleming" <[email protected]>
>To: <aspectwerkz-devel-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org>
>Sent: Friday, January 09, 2004 9:46 AM
>Subject: [aspectwerkz-devel] 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
>>
>>
>> _______________________________________________
>> aspectwerkz-devel mailing list
>> aspectwerkz-devel-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
>> http://lists.codehaus.org/mailman/listinfo/aspectwerkz-devel
>>
>>