RE: [aspectj-users] advanced(?) percflow uses

["Gregor Kiczales" <gregor@xxxxxxxxx>]

By an example I mean that we need something that makes it 
clear it would really be useful. Your code just shows what
the semantics would be. It's the difference between saying:

 after(): call(m1) && call(m2) { doSomething(); }

which shows me what after advice does, and

 after(): call(void FigureElement+.set*(..)) {
   Display.update();
 }

which shows that after advice could really be useful.

What I think we all need to see, in the case of enclosingexecution,
is evidence that there are cases where using it would really
*reliably* get you what you want. That you wouldn't end up having
to write it another way. In particular, the issue with
enclosing execution has always been whether it would be too
brittle in the face of minor code refactorings. Consider the
following code

 pointcut hoistPoint(): enclosingExecution(call(void Record.update*(..));

  void updateAll(~~~) {
      setFirstName(~~);
      setLastName(~~);
      setSalary(~~);
  }

Now refactor the method slightly to:

  void updateAll(~~~) {
      updateName(~~);
      setSalary(~~);
  }

void updateName(~~~) {
      setFirstName(~~);
      setLastName(~~);
  }

Now the pointcut is going to match two points when you call updateAll.
Is that what you want? Maybe not.

So by example I mean something about as concrete as this, that is enough
to be convinced that the enclosingExecution pointcut would really work in
concrete practice.



> 
> :: Could you say a bit more about your example? Maybe some code 
> :: that suggests enough about it that it would be clear it 
> :: would really be useful? 
> 
> the general scenario: there are some methods doing complex computation
> in a subsystem, call it S. during this computation some Condition's
> happen that should be handled by the caller. if there was a
> Throwable.continue(Object returnValue) as there is in lisp, 
> or slate, i
> would be fine. but there isn't, so i simplified the scenario:
> 
> in the complex methods gather warnings (into a percflow() 
> aspect) and on
> the the call site (ui) grab the warnings and display them.
> 
> aspect WarningCollector percflow(pc())
> {
> 	pointcut pc(): call(* S.*(..));
> }
> 
> someUIMethod()
> {
> 	S.complexMethod();	// the aspect is alive only under this
> call
> 	
> 	WarningCollector.aspectOf().getWarnings();	// the aspect is
> not alive here anymore
> }
> 
> 
> S.complexMethod()
> {
> ...
> 	if (WarningCollector.hasAspect())
> 	{
> 		WarningCollector.aspectOf().addWarning("foo");
> 	}
> ...
> }
> 
> 
> with your proposed enclosingexecution() i can define the percflow()
> expression in terms of the few well defined methods of S. without it i
> need to use call() and list all the call sites from where the 
> methods of
> S are called.
> 
> aspect WarningCollector percflow(pc())
> {
> 	pointcut pc(): enclosingexecution(call(* S.*(..)));
> }
> 
> hope it's clear, and maybe we'll have another joinpoint... :) would be
> helpful in this scenario.
> 
> thanks,
> 
> - 101
> 
> 
> :: > -----Original Message-----
> :: > From: aspectj-users-admin@xxxxxxxxxxx
> :: > [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of 
> :: Lendvai Attila
> :: > Sent: Thursday, February 26, 2004 8:52 AM
> :: > To: aspectj-users@xxxxxxxxxxx
> :: > Subject: [aspectj-users] advanced(?) percflow uses
> :: > 
> :: > 
> :: > 
> :: > hi,
> :: > 
> :: > is there a way to define a percflow aspect so that it 
> :: lives one level 
> :: > above the percflow expression? what i would like to do is 
> :: to define a 
> :: > percflow aspect that is alive in the entire method from 
> :: where a given 
> :: > set of other methods are called.
> :: > 
> :: > and on an even higher level: i would like to write a 
> :: WarningCollector 
> :: > aspect that my session bean methods can fill up, and the 
> :: ui methods 
> :: > can query for warnings.
> :: > 
> :: > aspect WarningCollector percflow(sessionBeanMethods())
> :: > {
> :: > }
> :: > 
> :: > void someUIMethod()
> :: > {
> :: > 
> :: >   someService.someEJBMethod();
> :: > 
> :: >   WarningCollector.aspectOf().getWarnings();
> :: > 
> :: >   // unfortunately on this level the aspect is not alive 
> anymore }
> :: > 
> :: > the only solution i know of is to list not the ejb methods in the
> :: > percflow() definition, but rather the methods that call any
> :: > ejb method.
> :: > but this is not a nice way to do, error-prone, etc.
> :: > 
> :: > any ideas?
> :: > 
> :: > thanks in advance,
> :: > 
> :: > - 101
> :: > 
> :: > _______________________________________________
> :: > 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
> :: 
> :: 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>