2008/12/9 Dave Whittaker <[EMAIL PROTECTED]>: >> 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 <[EMAIL PROTECTED]>: >>>> >>>> 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 >>> [EMAIL PROTECTED] >>> >>> 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 >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>> >>> _______________________________________________ >>> aspectj-users mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>> >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users >
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
