[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Use Cases for Changing target and this in proceed
|
Wes,
Thanks for the quick reply...
On Dec 13, 2004, at 3:31 PM, Wes Isberg wrote:
However, I haven't been able to come up with a
realistic use case for changing the "this" object.
One use is to apply the strategy pattern to a template method.
Another would be to cache a local copy of a remote object; a
variant of this would be to batch updates. The basic idea is
that there are policies with different behavior or state that
one might want to apply using proxy-like behavior in situations
where you can't manage the references held by the client.
Perhaps I'm being dense, but these seem to be examples of changing the
target object. I'm trying to find a use case where it makes sense to
cause subsequent advice to think that the original client was different
(neglecting execution point cuts where target and this are confounded).
Do you think this is a case where AspectJ is too powerful? Would the
language be simpler or more complex if you couldn't
replace this or target?
My intuition is that eliminating the ability to change the target
object would sacrifice too much power. It is fairly easy to come up
with use cases where it is helpful to change the target object.
However, I don't yet understand why one would want to change the "this"
object.
(Warning, the rest of this message gets into speculative language
design questions. And, lest you think I'm an interloper, please note
that I am not advocating for changes to AspectJ. I'm just pondering
alternative design decisions.)
Omitting the ability to change this or target without making any other
changes to the language would seem to make the language more complex:
certain parameters to proceed would follow different rules than other
parameters. But I wonder if a language might use a different form for
proceed where the arguments matched those of the original join point
instead of the parameters of the surrounding advice. The target object
could be changed by prefixing the proceed with "target_expression."
For example:
void around(A tar, int arg) : call(void m(int)) && target(tar) &&
args(arg) {
new A().proceed(arg * 2); // equivalent to current AspectJ's
proceed(new A(), arg)
}
This would match the intuition that a proceed is like the original
triggering event for the join point, but with new data. It also
eliminates the confusion that can arise when two different advice
parameters are bound to the same join point data and the proceed
changes just one of them, as in the following AspectJ code:
void around(A tar1, A tar2) : call(void m()) && target(tar1) &&
target(tar2) {
proceed(tar1, new A()); // the actual target is the new A, or
generally whichever is right-most
}
In the design I'm pondering that last proceed would be written "new
A().proceed()", eliminating any confusion about the actual target.
There are a variety of issues with the design I'm pondering, including
1) confounding the proceed special form with a call to a method named
proceed, 2) determining the type for proceed when the pointcut doesn't
yield a unique type for the originally called method, and 3) not being
able to change the _this_ object.
I'm trying to understand how big the loss is in issue 3.
Best,
Curt
----------------------------------
Curtis Clifton, PhD Candidate
Dept. of Computer Science, Iowa State University
http://www.cs.iastate.edu/~cclifton
