It sounds to me like maybe the best idea would be to table the
conversation on the "delegation" route for now. I still think that it
would be a nice feature to have, but with less caffeine in my system
this afternoon it is seeming like it might be a bit overly ambitious
for a starting point.
So it seems to me that if we stick to discussing methods whereby we
can simplify the current process, we have three different proposals:
a) Place the intertype members for a particular interface into a code
block, i.e.
public aspect ITDAspect{
intertype(ITDInterface){
private String string;
public String getString(){
return string;
}
public void setString(String string){
this.string = string;
}
}
}
b) Use a declare statement to define all methods of a plain java class
as belonging to another type, i.e.
declare extends: ITDInterface, ITDDefaultImpl;
c) Use a declare statement to define all methods of a class which are
contained in a given interface as applying to classes which match a
pointcut, i.e.
declare parents: ITDInterface+ implements ITDInterface defaultImpl
ITDInterfaceImpl;
I've changed the syntax there to read more like a sentence as Hermann
suggested, and also brought it more in line with the @DeclareParents
annotation that Ramnivas has mentioned. It may look strange in this
case to see a pointcut matching the interface causing the target to
implement that same interface, but the addition of defaultImpl is the
key that would allow adding ITD members to a class based on the
interface it defines, and it appears that since the @DeclareParents
annotation does exist that capability is already present to some extent.
Am I correct on those as the distinct possibilities? If so it seems
like the trade off is that with b and c you get greater flexibility,
but you also make things more complex by introducing the possibility
that the source class may itself extend another class. So I guess
the question I'd have for anyone who has used the annotation approach
is, how does that work currently? If it is a problem, what about
forcing the source objects to extend java.lang.Object? I think that
personally I'd prefer the declare statement if the inheritance issue
can be handled gracefully because it would be great to define
intertype members in a plain java class within eclipse in a plain java
editor with all the goodies available therein, but really I'd be happy
with any of these.
On Dec 5, 2008, at 6:32 AM, Simone Gianni wrote:
Hi Herman,
you perfectly got the point. We are moving from IDT to something
else, and that what I felt in the first place without being able to
express it with the clarity you had. I agree on splitting this
thread on "A simpler syntax for IDTs" and "A delegation approach to
IDTs".
As long as the simpler syntax for IDTs in involved, I like Dave's
proposal, also because it uses a construct very similar to the
"with", which is present in a number of languages but missing in
Java, and many programmers are already used to it. Also, it simply
requires less typing without changing the semnatics of the IDT.
There can be better ways of doing mixins/IDTs, including the
delegation based ones, but that's another discussion.
Simone
----- Messaggio originale -----
Da: Ichthyostega <[EMAIL PROTECTED]>
A: [email protected]
Posta Inviata: giovedì 4 dicembre 2008 22.42.08 GMT+0100 Europe/
Berlin
Oggetto: Re: [aspectj-users] ITD syntax
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dave,
> I'm glad for this discussion because it's helped me in refining
how I think
> this would work best.
Same here. I saw your answer just after posting mine.
Probably we are facing a decision on two possible routes to take:
- - provide some convenience for Delegation using AspectJ
- - stick to the ITD semantics but provide a better syntax.
My feeling is we would be best off if we took a clear decision on
one of those routes and don't try to mix them up. Even if we were
able to come with a combined solution, it will confuse people.
Thus, if we go the "Delegation" route, "this" should be really
rebound
the moment we are within the scope of the delegate to mean the
delegate,
the same way as if all of this was just implemented in plain Java.
OTOH, when going the "ITD" route, the source class (ITDDefaultImpl
or DoSomethingImpl) is rather sort-of a template for code woven into
the target. I.e., at runtime, no class DoSomethingImpl will be
loaded.
Then the question remains what should happen with private fields.
Consider, both the class Doer and class DoSomethingImpl may use
a private field with the same name for their implementation.
Hermann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJOE6wZbZrB6HelLIRAjRcAJ9lpaNl/nFsSX/dTl34LL364s5qyQCfQ8wS
CmLlX5bTe+LvoI6V8sh29K8=
=EYAe
-----END PGP SIGNATURE-----
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
