| 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 <prg@xxxxxxxxxxxxxxx>
A: aspectj-users@xxxxxxxxxxx
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
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/aspectj-users
|
