Re: R: Re: [aspectj-users] ITD syntax

[Ichthyostega <prg@xxxxxxxxxxxxxxx>]

-----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-----