[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: R: Re: [aspectj-users] ITD syntax
|
Assuming the delegate model is supported with code-style syntax, do we
need simplified syntax for the insertion model (option a)?
Since it appears that we do already have two different models of mixin
in AspectJ, the standard method through qualified statements and using
delegation with annotations, and it seems that both methods are
complementary to each other, then I'd say that yes option a would
still be a useful simplification of the first model. That said, I
personally think that the delegation model if allowed through a
declare / defaultImpl statement would be a much more useful
enhancement, so if we have to focus on one change for now I'd vote for
that.
Having an nested block is very similar to using an inner
class. It can make for very elegant and compact code which you just
read once
top down and understand everything what's going on. Or, when the
nested block
gets too much involved, you easily create an confusing and
intimidating mess.
That's true, but lets face it, it's near impossible to create
constructs that people can't in some way turn into a mess. The best
we can to is to provide a mechanism by which they can write simple,
clean, readable code. If it's a question of which is more readable:
public String AnotherClass.someVar;
public String AnotherClass.getSomeVar(){
return someVar;
}
public void AnotherClass.setSomeVar(String someVar){
this.someVar = someVar;
}
-OR-
intertype(AnotherClass){
public String someVar;
public String getSomeVar(){
return someVar;
}
public void setSomeVar(String someVar){
this.someVar = someVar;
}
}
Then to me there is no contest.... most of the second method looks
like plain java code, which is what we are all used to writing in.
And that's before the copy/paste and other benefits of writing in
something more like plain java code provides.
Regarding the *model* i.e. the semantics, I'm not at all sure if we
indeed are
discussing two or three different models. Especially, does b) differ
from the
other proposals semantically?
Option B was the original syntax Ramnivas used that got us thinking
about how a POJO could provide the mixed in methods if it was targeted
by a declare statement. Option C was me trying to refine that a bit
to make it more descriptive regarding just what was being inherited
and also trying to make it more like the existing @DeclareParents.
Hermann, as far as your other concerns go... While I am admittedly not
very knowledgeable about how binary class files are structured, I
think that maybe these problems are something that AspectJ already
provides some solution for. Since we already have ITDs, and we
already have delegation through @AspectJ and @DeclareParents (we think
we do anyway, maybe a developer could clarify how that works?) so I
would think that perhaps we should follow the "if it ain't broke,
don't fix it" rule and maintain the same method of providing the
methods and fields to the targeted class. I don't believe the new
syntax would change the effectiveness of the current implementation,
do you?
Dave Whittaker
Iradix, LLC
(p) 212.513.0874 x100
(f) 212.504.8213
dave@xxxxxxxxxx
On Dec 6, 2008, at 12:44 PM, Ichthyostega wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Ramnivas Laddad schrieb:
There are indeed two different model for implementation for ITDs...
So I guess we have two questions to ponder:
1. Do both model make sense.
2. What is best syntax for "bulk ITD"
Dave Whittaker schrieb:
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
b) Use a declare statement to define all methods of a plain java
class as
belonging to another type
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
So basically we should discuss two distinct issues: the syntax and the
implementation semantics (model). Regarding the syntax, there seems
to be
agreement that the current syntax gets clumsy the moment you
introduce a
set of members, as it doesn't make clear what belongs together.
Moreover,
all seem to agree that the alternate syntax proposed in a) and c)
looks
interesting, i.e
- - have a nested block within the aspect which looks like a nested
class
- - use a special declare parents statement mentioning a defaultImpl.
Probably both are good options and IMHO have distinct pros and cons
depending
on the circumstances. Having an nested block is very similar to
using an inner
class. It can make for very elegant and compact code which you just
read once
top down and understand everything what's going on. Or, when the
nested block
gets too much involved, you easily create an confusing and
intimidating mess.
The declare parents statement is already there, but without the
delegation
option only available for annotation style aspects. Before Ramnivas
pointed it
out, I too wasn't aware it existed at all. I think, this one is just
an omission
which should be corrected.
http://www.eclipse.org/aspectj/doc/released/adk15notebook/ataspectj-itds.html
Regarding the *model* i.e. the semantics, I'm not at all sure if we
indeed are
discussing two or three different models. Especially, does b) differ
from the
other proposals semantically? Or is it just a variation of the
delegation model
c) inasmuch as the interface is extracted on-the-fly based on the
public methods
of the default implementation class? Or, is this model b) a somewhat
obscured
form of multiple inheritance?
When reconsidering multiple inheritance as known from C++, a
distinguishing
factor seems to be the complete symmetry between the multiple chains
of
inheritance. They are on equal footing, while in the Java/AspectJ-
style model,
there is clearly one main line which takes precedence without
further notice.
E.g. the "hashCode()" of the main line wins, even if the default
implementation
of a mixin line also specifies a "hashCode()", right?
Another point worth noting is that with multiple inheritance, all
(virtual)
methods end up in the same combined vtable, making it possible to
build on
points of extension created within one of the multiple ancestor
lines. Something
like "this.canDoSomething()" in Dave's example. Overriding it in the
combined
class influences the logic within DoSomethingImpl. In a delegation
based
solution this can't be the case, because here the delegate remains a
separate class with complete encapsulation.
This leads us to what seems to be the most difficult issue for a
bulk ITD
feature /not based on delegation/ : how to deal with encapsulation
and state.
If you write something that looks like an (inner) class, chances are
that users
expect it to behave like an (inner) class. Such a feature will be
worthless
without the ability of using additional state, i.e. private fields.
Now,
who owns them and who can access them? And how to handle name clashes,
i.e. multiple bulk ITD blocks (maybe even from different aspects)
using the same private field name?
Hermann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJOroAZbZrB6HelLIRAjd9AJ9pK6CCE3aEOAHKlRyrkSsr6AxocQCg5Uyp
CRQ4TSufjfvy/OvY+6/9yzw=
=UxS7
-----END PGP SIGNATURE-----
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
