[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] Parameters
|
As I recall, the issue with using .. more than once in an args pointcut
is as follows:
consider three pointcuts
p1(SpaceShip s): args(s, ..)
p2(SpaceShip s): args(.., s)
p3(SpaceShip s): args(.., s, ..)
and a method like:
void collide(SpaceShip s1, SpaceShip s2) { <make a big flash> }
Well p1 and p2 both match calls or executions of this method. But
what about p3? Should it match? Should it not match? Should it
match *twice*?
Its not clear (at least to me). There are some interesting things
you could do here, but figuring them out could take some time.
Because not allowing more than one .. neatly avoids this problem,
that is what we did. We weren't saying that was the right decision
for all time. But I think it was right for 1.0.
Note that this is NOT a comment on whether .., x, .. in the unambiguous
case is useful. I think it is, and that's why we tried to figure it out.
Its just a statement that the ambiguous case seems to interfere here.
> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx
> [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of DiFrango, Ron
> Sent: Wednesday, August 20, 2003 9:54 AM
> To: 'aspectj-users@xxxxxxxxxxx'
> Subject: RE: [aspectj-users] Parameters
>
>
> Wes,
>
> In thinking about the problem more fully, I see (in my humble
> opinion) a
> limitation (severe if you consider legacy systems) in the way aspectj
> handles the arguments to methods in defining PCD. If you
> look at the way it
> works today, aspectj requires that if you have a need to pull
> out on certain
> parameters to a given method, you must define (and must
> continue to require)
> the order in which they are defined in order to expose them
> to the advice.
>
> To give you an idea of where I am using this is that I want
> to pull out all
> the common argument/parameter validation rules that current
> have scattered
> all over the place in our code base with one central
> validation service via
> aspectj. If I am required to re-order the
> arguments/parameters to these
> methods I may end up touching somewhere around 300 to 400
> classes. On the
> flip side if I could pick-out the arguments any where they
> exist I would
> only have to affect 62 classes or the ones that have the
> rules in them.
>
> Please let me know if I am wrong of off base with this assessment.
>
> Thanks,
>
> Ron DiFrango
>
>
> -----Original Message-----
> From: DiFrango, Ron
> Sent: Wednesday, August 20, 2003 8:47 AM
> To: 'aspectj-users@xxxxxxxxxxx'
> Subject: RE: [aspectj-users] Parameters
>
>
> Wes,
>
> Thanks for your answer and it does not work in 1.0 as that is
> the version I
> am on currently. Actually it was what I expected. I am
> surprised that I am
> one of the first to bring this up.
>
> I personally would like to see the ability to use multiple
> wildcards in a
> PCD. The main driver for me is that I am retrofitting old
> code and I would
> prefer to keep the pre-existing interfaces as much intact as possible.
>
> Should I submit a bug report on this?
>
> Thanks,
>
> Ron DiFrango
>
>
> -----Original Message-----
> From: Wes Isberg [mailto:wes@xxxxxxxxxxxxxx]
> Sent: Wednesday, August 20, 2003 12:03 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: Re: [aspectj-users] Parameters
>
>
> args(.., ClassX, ..)
>
> should have worked in AspectJ 1.0, but, as Erik noted for 1.1,
>
> We did not implement the handling of more than one ..
> wildcard in args PCDs (rarely encountered in the wild)
> because we didn't have the time. This might be available
> in later releases if there is significant outcry
>
> http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspect
> j-home/doc/REA
> DME-11.html#language
>
> I'm not sure if a bug would qualify as a significant outcry,
> but it would be
> a place others could chime in.
>
> (Also, it's a doc bug that ".." in args(...) is not better
> documented. I
> couldn't find it in either quick reference or the programming guide
> semantics appendix; perhaps my search was bad.)
>
> A workaround for now is to test the args directly, perhaps
> even in an if
> pointcut:
>
> aspect A {
> private static boolean hasArg(Class c, Object[] args) {
> for (int i = 0; i < args.length; i++) {
> if ((null != args[i]) &&
> c.isAssignableFrom(args[i].getClass())) {
> return true;
> }
> }
> return false;
> }
> before() : ... && if(hasArg(ClassX.class,
> thisJoinPoint.getArgs()) {
> ...
> }
> }
>
> Obviously, that won't pick out a null ClassX arg, and it
> can be expensive, depending on the rest of your pointcut.
>
> Wes
>
>
> DiFrango, Ron wrote:
>
> > All,
> >
> > I could not find an answer to this in any of the old
> postings. I have
> > methods that take a common parameter. The problem is that
> depending
> > on the method call this parameter may be listed anywhere in
> the method
> > signature. So for example:
> >
> > public class ParametersInMethodCalls
> > {
> > public void example1(ClassX x, double I, String s)
> > {
> > }
> >
> > public void example2(int I, ClassX x, double d)
> > {
> > }
> >
> > public void example2(float I, String s, ClassX x)
> > {
> > }
> > }
> >
> > My question is can I define a pointcuts that picks out all the above
> > combinations without having to "code if you will" the different
> > permutations possible? I have tried the following
> > examples/permutations:
> >
> > pointcut examples(ClassX x) :
> > execution(public * ParametersInMethodCalls.*(..))
> > && args(.., x);
> >
> > ==> Afected example2
> >
> > pointcut examples(ClassX x) :
> > execution(public * ParametersInMethodCalls.*(..))
> > && args(x, ..);
> >
> > ==> Afected example1
> >
> > pointcut examples(ClassX x) :
> > execution(public * ParametersInMethodCalls.*(..))
> > && args(*, x);
> >
> > ==> Affect nothing
> >
> > The important thing to note is that all the methods I want
> to pick out
> > have the common input of ClassX, but there is an
> indeterminate number
> > of other parameters to these methods. Furthermore, I would
> prefer to
> > avoid having to change the underlying code as it affects a
> large body
> > of code.
> >
> > Thanks in advance,
> >
> > Ron DiFrango
> >
> >
> **********************************************************************
> > ****
> > The information transmitted herewith is sensitive
> information intended
> only
> > for use by the individual or entity to which it is addressed. If the
> reader
> > of this message is not the intended recipient, you are
> hereby notified
> that
> > any review, retransmission, dissemination, distribution, copying or
> > other use of, or taking of any action in reliance upon this
> > information is strictly prohibited. If you have received this
> > communication in error, please contact the sender and delete the
> > material from your computer.
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> **************************************************************
> ************
> The information transmitted herewith is sensitive information
> intended only
> for use by the individual or entity to which it is addressed.
> If the reader
> of this message is not the intended recipient, you are hereby
> notified that
> any review, retransmission, dissemination, distribution,
> copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> **************************************************************
> ************
> The information transmitted herewith is sensitive information
> intended only
> for use by the individual or entity to which it is addressed.
> If the reader
> of this message is not the intended recipient, you are hereby
> notified that
> any review, retransmission, dissemination, distribution,
> copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
