[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: R: Re: [aspectj-users] ITD syntax
|
I can see work forming before my very eyes on this thread :) It is
all useful discussion though.
Relating to the multiple inheritance part of the discussion, keep this
enhancement request (raised by Dave/Ramnivas) in mind:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=253784
The @DeclareParents delegation/mixin model was created to offer
something like ITDs for users working in annotation style. In that
world we don't control the type system during compilation so have to
have code that javac will tolerate. It is not as polished as code
style AspectJ, but it could be. And there are no restrictions on
using @DeclareParents if you are in a code style aspect (or at least
there shouldn't be). We have numerous open bugs to better document
the distinction between annotation style @DeclareParents and regular
code style declare parents.
I like the idea of simplifying the syntax but I keep changing my mind
over the syntax I most prefer. It is probably this actually:
> intertype(AnotherClass){
>
> public String someVar;
>
> public String getSomeVar(){
> return someVar;
> }
> }
Since everything is there and it is clear. I'm just nervous about new
keywords and how easily I can persuade the compiler to deal with it.
I would see this just as syntax sugar on the current ITD model though,
and not change any semantics to say that it means anything like a
mixin/delegation model.
I'm not sure I like this too much as it takes me a couple of readings
to understand:
declare parents: ITDInterface+ implements ITDInterface defaultImpl
ITDInterfaceImpl;
If we could come up with a prettier version of this I might consider
it as the code style variant of @DeclareParents - offering
delegation/mixin to code style users.
Andy.
2008/12/8 Dave Whittaker <dave@xxxxxxxxxx>:
>> 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
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
