Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Parameters

Gregor,

In thinking about this more, if I were the one writing the requirements, I
would want the situation you pose below to have two (or more if that is how
the method call is structured) matches.  In my case, I am trying to do
contract enforcement so there is nothing that I would not want to happen on
all instances of that object.  Personally, I think that this is a better
limitation, if you will, than the current one because I must declare point
cuts with every combination of parameters that I might encounter now and in
the future.  The other alternative is to enforce some form of arbitrary
architectural standard that certain parameters must be in certain orders,
etc. which I think becomes difficult at best.  Furthermore, I believe that
this defeats the purpose of cross-cutting concerns because now my code
essentially know that it will be cross-cut in some manner.

Maybe aspectj could provide some sort of mechanism to say I want to enforce
this on all parameters or not.

Thanks,

Ron DiFrango


-----Original Message-----
From: Gregor Kiczales [mailto:gregor@xxxxxxxxx] 
Sent: Wednesday, August 20, 2003 1:22 PM
To: aspectj-users@xxxxxxxxxxx
Subject: 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
> 


_______________________________________________
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.


Back to the top