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

(pc within X) or (pc2 within Y)

pc within X or pc within Y
pc within (X or Y)

pc within (X and Y)

pc1 and pc2 within X
pc1 and (pc2 within X)

pc within X within Y => FAILS
Please use: pc within (X and Y)


Better ?
Consequences:
There is an "and / AND / &&" operator for Filter typed expressions
"within" has higher priority than "and" (and "or")

Alex

----- Original Message -----
From: "Craig Fleming" <[email protected]>
To: <aspectwerkz-devel-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org>
Sent: Monday, January 12, 2004 6:15 PM
Subject: [aspectwerkz-devel] Re: [aspectwerkz-user] proposed syntax: within
construct, feedback wanted


> So which would you end up with
>
> /**
>  * @Around executionPointcut within fooFilter && blahFilter &&
> someOtherFilter
> */
>
> or
>
> /**
>  * @Around executionPointcut within fooFilter within blahFilter within
> someOtherFilter
> */
>
> The first makes some amount of sense. The second has far too many
> within's. Not only is there a within keyword for each filter in the
> advice selection, but also one for each filter when you declare the
> filter!
>
> Craig
>
> On Sat, 10 Jan 2004 00:24:51 +0100, "Alex"
> <alex-he/e8N7AIe/[email protected]> wrote:
>
> >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%20s
c
> >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
> >>
> >>
>
>
> _______________________________________________
> aspectwerkz-devel mailing list
> aspectwerkz-devel-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> http://lists.codehaus.org/mailman/listinfo/aspectwerkz-devel
>
>