[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: R: Re: [aspectj-users] ITD syntax

I'd be happy to write the documentation up when the time comes.  I can get a bit sidetracked based on my workload, but as long as I know the features are ready for documenting I'll make sure it gets on my calendar.  No problem with the debugging as well.  My debug information is coming from real projects I've been working on so I appreciate the effort you guys put into fixing them so quickly.

I would find @DeclareMixin to be a much clearer name than @DeclareParents, my only hesitation with that is... isn't an ITD also technically a mixin?  I wouldn't be surprised if I'm wrong here, but my impression of the term mixin is that it refers to any method of applying members defined within one type to another type.  I just wonder if seeing that for the first time I wouldn't have thought it does the same thing as an ITD and while they are mostly interchangeable in some ways they aren't, like the need for an interface defining the mixed in methods when using @DeclareParents.  @DeclareDelegate may better explain that the annotation and associated statement implement mixin through delegation, which is a pattern I'd imagine most java developers are familiar with.

I think you make a good point about the period type syntax for ITDs, I hadn't really thought about having a keyword to search for.

So before I post a feature request in bugzilla, I just want to make sure that everyone who has contributed to this thread (and thanks to all that have) agrees in principle on what the request(s) should be.  I'm seeing it right now as really two separate requests, one for a new syntax for code style ITDs and another for a "declare" statement that offers the same functionality as the @DeclareParents annotation, along with possibly renaming that feature to make it less confusing.  Does that sound about right?

On Dec 10, 2008, at 1:37 PM, Andy Clement wrote:


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
>

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users