[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: R: Re: [aspectj-users] ITD syntax
|
2008/12/9 Dave Whittaker <
dave@xxxxxxxxxx>:
>> I can see work forming before my very eyes on this thread :)
>
> Aren't you glad I've taken such an interest? :) Actually, I do feel bad
> about laying this out there without volunteering much towards the
> development process. I would like to get the project building soon so I can
> at least look the code over and see what type of contribution I might be
> able to make. Do you have any recommendations on what classes to start
> looking at? At the very least I would be willing to write up some
> documentation if this does get implemented.
The work you do exercising the ITD stuff (especially generic ITDs) and the
quick responses you give to me when I need more debug info is an invaluable
contribution already. If you could find time to write some documentation on
these features when we add them, that would be great.
>> 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>
> I have and I had kind of hoped that might be something we could work in if
> these changes do get made. With the delegation model this could be as easy
> as a method for retrieving the delegate.
>
> public ITDTarget implements ITDInterface{
>
> public void itdMethod(){
> ..do something first..
> AJUtils.getDelegate(this, ITDInterface.class).itdMethod();
> ..do something after..
> }
>
> }
>
> For code style ITDs I think syntax like ITDInterface.super.itdMethod() is
> probably the most clear method of accessing the ITDs members. I don't know
> how difficult that might be to implement though.
Actually I think this can be something we just keep in mind whilst designing/implementing
the new syntax - it probably is a separate piece of work now I think it through. If I were to
do a helper method I might do something akin to what we already have.
ITDInterface.super.itdMethod() (or similar) is probably the easiest to implement, I think, but
we already ship a helper class called 'Aspects' for use when needing to call
aspectOf() or hasAspect() when in an annotation style aspect, so if I did add a helper
for this, it would probably go in there.
Aspects.delegateOf(this,ITDInterface.class) // thinking out loud
> declare delegate: ITDInterface defaultImpl ITDInterfaceImpl
>
> would be clearer? If so, maybe moving from @DeclareParents to a
> @DeclareDelegate annotation might be in order as well, since it's something
> that can't be done with a declare parents statement right now....
We shouldn't feel bound to @DeclareParents in coming up with the right
code style syntax. I feel @DeclareParents has the wrong name anyway as users
often complain that it doesn't do the same as 'declare parents' - and they are
right - it should probably be called something else. @DeclareDelegate may be
the answer, or maybe @Mixin or @DeclareMixin as I think have been proposed before
I'm not sure about complexity of implementation without trying out a few things. My
gut feeling is that
intertype TargetClass {
...
}
might be the easiest (and clearest)
TargetClass.{...}
is likely to cause me a problem and may freak out people when they first see this, I mean
they won't even know what to google to work out what is happening. At least the keyword
intertype would give them something to look up :)
I guess it is time to raise an enhancement to cover this. Then bash out some
testcases/use-cases (community input on those would be great).
Andy.
>
>
> On Dec 8, 2008, at 2:30 PM, Andy Clement wrote:
>
>> 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
>>>
>> _______________________________________________
>> 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
>
