Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] ITD syntax 
Simone,
I think I see what you are saying, but can you just clarify the difference between an ITD and a mixin for me? I had always thought of them as being interchangeable, but I'm admittedly more familiar with the use of aspects than the theory.
I think that you are correct that keeping fields "private to the aspect" should not be violated, but couldn't this be implemented using the standard delegation pattern that most people seem to recommend for implementing multiple inheritance in Java? The declare statement could cause any advised class to hold a reference to the class that contains the default implementation and then automatically create the delegate methods for you as per the interface. Since only the methods in the interface would be added even if the class containing the default implementation were to implement other methods or extend other classes, the user would not be aware (which i think solves your other problem). I guess this would be more of a complement to ITDs than an alternative implementation since it would not allow the creation of methods that aren't contained in the interface but personally, I would see that as a positive thing for most of my own use cases.
What this basically boils down to for me is that the Java powers that be have dictated, no multiple inheritance unless it's done with interfaces and delegation, which works but a) it's an enormous pain to create the delegate methods and then keep them in sync for every targeted class and b) references to "this" inside a class that's being delegated to don't do what they'd do in a situation where true inheritance was involved. If AJ could solve both of those issues and make it as easy as a declare statement, I'd imagine I'm not the only person that would be useful to.... What do you all think? 

On Dec 4, 2008, at 12:22 PM, Simone Gianni wrote:


Hi Ramnivas and Dave,
yes, I also liked the proposal, in fact I also find the ITD syntax a bit 
too verbose.
Ramnivas, your proposal moves from ITD to something near mixins, which I really like :). Anyway, that class could be every class, and that bring 
a number of problems, cause it could extend another class, and since
Java does not support multiple inheritance we should not give the user
the feeling that it is happening. Also, the fact that a ITD field is
private "to the aspect"is a very good feature, I already have more than 
one aspect declaring a "inited" boolean field, each aspect uses it to
mark a certain instance inited regarding its own concern. I see not much 
a technical problem in obtaining the same behavior with your proposal,
but again a problem from a user POV.

The direction seems correct to me, but some boundaries must be defined
to give the user the proper feeling of what they are doing.

Simone


Ramnivas Laddad wrote:

I like this proposal.

Here is an alternative syntax suggestion that
- addresses Dave's use case
- addresses a use case that is easy to implement in @AspectJ but not
in code style
- avoids new keywords

public aspect ITDAspect{
/* don't have define the class here, don't need to make it private; 
       but defining it that way matches Dave's example
  */
   private static class ITDDefaultImpl {
       private String string;

       public String getString(){
           return string;
       }

       public void setString(String string){
           this.string = string;
       }
   }

   /* declare that ITDInterface should be introduced with
       all fields and methods in ITDDefaultImpl
       Not sure about the choice of using "extends"
       (trying to avoid new keyword)
       Alternatives: declare implements? declare default?
   */
   declare extends: ITDInterface, ITDDefaultImpl;
}

This makes a common use case implemented by the following @AspectJ
snippet available in the code style syntax. Essentially, I get to
reuse the implementation available from an existing class.

@DeclareParents(value="com.myco.domain.*",
                            defaultImpl= ITDDefaultImpl.class)
ITDInterface something;

How does this sound?

-Ramnivas
On Wed, Dec 3, 2008 at 9:40 PM, Andy Clement <andrew.clement@xxxxxxxxx > wrote:
I could be wrong but I think I recall someone talking about something 
like this a while ago - possibly Ramnivas.  Although having just
trawled through our enhancement requests, I only found this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=240011 which is about
saving typing but isn't quite the same thing.  What you propose is
interesting, what do others think?

cheers,
Andy.

2008/12/3 Dave Whittaker <dave@xxxxxxxxxx>
I've been wondering recently.... is there a reason that ITDs are defined the way they are? I don't know how others tend to use them, but for me I'm pretty likely to have an aspect that contains ITD fields and methods that apply to a single interface within a given aspect. This makes me wonder why we have a syntax like: 

public aspect ITDAspect{

      private String ITDInterface.string;

      public String ITDInterface.getString(){
              return string;
      }

      public void ITDInterface.setString(String string){
              this.string = string;
      }

}

Instead of:

public aspect ITDAspect{

      intertype(ITDInterface){


              private String string;

              public String getString(){
                      return string;
              }

              public void setString(String string){
                      this.string = string;
              }

      }
}
Or something similar. Something that involved less typing, consolidated code that is defined for another type and looked more like plain java code (not to mention more like other AJ definitions in this case....). At the very least it would allow for something that I've wanted many times: cut and paste between classes and ITDs without having to post process with some sort of wacky regex. Am I missing a reason why it's desirable or even necessary to type out the full interface name on each line? 
_______________________________________________
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




--
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
http://www.simonegianni.it/

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

Back to the top