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

almost there

Ideally i d like the "within" operator in the expression language (see
@Around)

Alex

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

 /**
 * @Around executionPointcut within fooFilter
 */



----- Original Message -----
From: "Craig Fleming" <[email protected]>
To: <aspectwerkz-devel-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org>
Sent: Saturday, January 10, 2004 4:04 AM
Subject: [aspectwerkz-devel] 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%20sc
o
> >> >> 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
> >>
> >>
>
>
> _______________________________________________
> aspectwerkz-devel mailing list
> aspectwerkz-devel-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> http://lists.codehaus.org/mailman/listinfo/aspectwerkz-devel
>
>