Revamping simplified ITD syntax

[Simone Gianni-2]

Hi all AspectJ users.

There has been a discussion, about one year ago, about a simplified
syntax for ITDs. The discussion then diverged in another thread about
various ways of implementing ITD, which was not the original proposal
made by Dave Whittaker.

During one more year of heavy ITD usage in my Apache "Magma" Lab, I had
time to think about it much deeper, and concluded that the original
Dave's idea is quite right, but could even be improved.

So I'm writing to ask your ideas and comments on what follows.

The problem is that the current syntax that AspectJ use to alter the
Java type system (ITDs, but also declare parents, declare @xxx etc..) is
perfect if you are modifying a large number of classes. For example, all
classes annotated with such and such will implement this interface.

However, it is becoming more and more common the need to modify a single
class, adding a few methods, or adding annotations to it. In fact
annotations are becoming more and more important in Java programming,
with lots of framework depending on them, and lots of JSRs being
published to exploit annotations as much as possible. Having the ability
to "add" annotation on a class on a separate aspect, which could be
applied or not, is a very nice feature, but currently painful to obtain.

Think for example of applying JSR-303 validation annotations or JPA ones
on existing code using current syntax. Since annotations will be
different for each field, it is quite a pain and quite unreadable. The
power of patterns is, in these case, useless and counterproductive.

Dave's case of declaring fields and methods on the interface then used
in a declare parents, is a special and very common case of this situation.

So, taking from Dave's proposal of introducing a new "intertype"
keyword, I'd like to put the bar a little higher and propose the
introduction of the "on" keyword. Please note that this syntax is not a
complete alternative to the existing one, but is a complementary syntax
for the described use cases.

A simple example will give a quick idea of how it could work :

public class MyOldBean {
  private String name;
  private String surname;

  public MyOldBean(int i) { ... }

  public void doThat() { ... }
}

public aspect RevampMyOldBean {
  @ClassLevelAnnotation
  on MyOldBean implements NewInterface {
    // new field
    @FieldLevelAnnotation
    private String newField;

    // new constructor
    @ConstructorAnnotation
    public MyOldBean(String _newfield) {
       ...
    }    

    // new method
    @MethodLevelAnnotation
    public String getNewField() {
      ...
    }

    // Existing field
    @FieldLevelAnnotation
    on String name;

    // Existing method
    @MethodLevelAnnotation
    on void doThat();

    // Existing constructor
    @ConstructorAnnotation
    on MyOndBean(int);
  }

  // Dave's case
  on NewInterface {
    public void doThis() { ... }
  }

}

If you think of how this has to be written with current syntax, you'll
notice how less readable and more error prone it is. I'm not saying it
will be necessarily "longer" in the sense of typing, except for Dave's
case where there is an obvious reduction of typing, I'm thinking about
readability and complexity more than mere number of keystrokes, but I'm
pretty sure also number of keystrokes will be reduced.

Moreover, refactoring methods from inside a class to an ITD aspect (or
the opposite) would be a matter of cut and paste.

I'm not a guru when it comes to formal language definition, but I think
the "on" keyword could be defined like this :

[<annotations>]
on <Type> [extends <TypeList>][implements <TypeList>][ { <ITDBlock> }

    * Annotations declared before the "on" keyword have to be applied to
      the specified type and are interpreted as "declare @type"
    * The "extends" and "implements" clauses, if present, are to be
      applied to the specified type and are interpreted as "declare parents"
    * The ITDBlock will contain new methods and/or the second form of
      the on keyword.


The second form appear inside the ITDBlock of another "on" keyword.

[<annotations>]
on <MethodSig>|<FieldSig>|<ConstructorSig>;

    * Annotations declared before the "on" keyword have to be applied to
      the specified member and are interpreted as "declare @method" or
      "declare @field" or "declare @constructor"
    * Eventually, instead of signatures patterns could be used, given
      that a complete signature is a specialized form of pattern.


As you can see, this could be implemented as plain syntactical sugar, it
could even be possible to write a set of regular expressions or a simple
parser to convert from this new syntax to the current one.

I'd love to try to code this inside AspectJ, and make this my first real
code contribution to the project.

WDYT?

Simone

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

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

[Andy Clement]

Worth quoting the related enhancement request I think - Dave's musings
on thread http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg10106.html
gave rise to https://bugs.eclipse.org/bugs/show_bug.cgi?id=261728

Out of interest, why did you feel the need to use 'on' rather than
intertype?  Just because it is a shorter option? Did it mean something
different to you than 'intertype'?  Do you think intertype scares
users? 'on' to me perhaps suggests activities executing based on some
event occurring, rather than what we are trying to do here.

>From that bug report:

public aspect ITDAspect{
  intertype ITDInterface{
    public String value;
    public String getValue(){
      return value;
    }
    public void setValue(String value){
      this.value = value;
    }
  }
}


If I dig through that old thread, there are some issues that I should
have added to the bug report but haven't yet.  Things like:
- does this new syntax provide a way to ITD a static initializer?
- does this new syntax provide a way to ITD an inner class?

Changes to the ITD syntax would clearly benefit something like Spring
Roo which makes heavy heavy use of ITDs.  It uses so many that I think
we could probably noticeably improve the compile times for Roo
projects by changing syntax.

But something that thread had not touched upon, nor does the current
enhancement request - but you have touched upon today - is the
annotation of existing members:

  // Existing field
  @FieldLevelAnnotation
  on String name;

  // Existing method
  @MethodLevelAnnotation
  on void doThat();

  // Existing constructor
  @ConstructorAnnotation
  on MyOndBean(int);

I feel like there might be another even neater way to express this,
but I can't quite put my finger on what it is.  If the current is:

declare @field: String name: @FieldLevelAnnotation;

Above we have:

@FieldLevelAnnotation on String name;

mmmm,

@+FieldLevelAnnotation String name;

Not sure.

> As you can see, this could be implemented as plain syntactical sugar, it could even be possible to
> write a set of regular expressions or a simple parser to convert from this new syntax to the current one.

syntax sugar is definetly the way to go initially - but it is not at
all trivial due to the grammar changes (if making it a real language
feature of AspectJ instead of transforming new syntax to existing).  I
can already picture some enhancements to the weaving code in the face
of large scale ITD usage if we can move to something more like this
model.  Perhaps regexs are the way to get some users refactoring their
code to try this style out and validate the constructs - before diving
into the heavy lifting of changing the grammar.  But i'm not sure how
a regex approach would affect incremental compilation analysis.

Andy.

2009/6/16 Simone Gianni <simoneg@...>

>
> Hi all AspectJ users.
>
> There has been a discussion, about one year ago, about a simplified syntax for ITDs. The discussion then diverged in another thread about various ways of implementing ITD, which was not the original proposal made by Dave Whittaker.
>
> During one more year of heavy ITD usage in my Apache "Magma" Lab, I had time to think about it much deeper, and concluded that the original Dave's idea is quite right, but could even be improved.
>
> So I'm writing to ask your ideas and comments on what follows.
>
> The problem is that the current syntax that AspectJ use to alter the Java type system (ITDs, but also declare parents, declare @xxx etc..) is perfect if you are modifying a large number of classes. For example, all classes annotated with such and such will implement this interface.
>
> However, it is becoming more and more common the need to modify a single class, adding a few methods, or adding annotations to it. In fact annotations are becoming more and more important in Java programming, with lots of framework depending on them, and lots of JSRs being published to exploit annotations as much as possible. Having the ability to "add" annotation on a class on a separate aspect, which could be applied or not, is a very nice feature, but currently painful to obtain.
>
> Think for example of applying JSR-303 validation annotations or JPA ones on existing code using current syntax. Since annotations will be different for each field, it is quite a pain and quite unreadable. The power of patterns is, in these case, useless and counterproductive.
>
> Dave's case of declaring fields and methods on the interface then used in a declare parents, is a special and very common case of this situation.
>
> So, taking from Dave's proposal of introducing a new "intertype" keyword, I'd like to put the bar a little higher and propose the introduction of the "on" keyword. Please note that this syntax is not a complete alternative to the existing one, but is a complementary syntax for the described use cases.
>
> A simple example will give a quick idea of how it could work :
>
> public class MyOldBean {
>  private String name;
>  private String surname;
>
>  public MyOldBean(int i) { ... }
>
>  public void doThat() { ... }
> }
>
> public aspect RevampMyOldBean {
>  @ClassLevelAnnotation
>  on MyOldBean implements NewInterface {
>   // new field
>   @FieldLevelAnnotation
>   private String newField;
>
>   // new constructor
>   @ConstructorAnnotation
>   public MyOldBean(String _newfield) {
>      ...
>   }
>   // new method
>   @MethodLevelAnnotation
>   public String getNewField() {
>     ...
>   }
>
>   // Existing field
>   @FieldLevelAnnotation
>   on String name;
>
>   // Existing method
>   @MethodLevelAnnotation
>   on void doThat();
>
>   // Existing constructor
>   @ConstructorAnnotation
>   on MyOndBean(int);
>  }
>
>  // Dave's case
>  on NewInterface {
>   public void doThis() { ... }
>  }
>
> }
>
> If you think of how this has to be written with current syntax, you'll notice how less readable and more error prone it is. I'm not saying it will be necessarily "longer" in the sense of typing, except for Dave's case where there is an obvious reduction of typing, I'm thinking about readability and complexity more than mere number of keystrokes, but I'm pretty sure also number of keystrokes will be reduced.
>
> Moreover, refactoring methods from inside a class to an ITD aspect (or the opposite) would be a matter of cut and paste.
>
> I'm not a guru when it comes to formal language definition, but I think the "on" keyword could be defined like this :
>
> [<annotations>]
> on <Type> [extends <TypeList>][implements <TypeList>][ { <ITDBlock> }
>
>   * Annotations declared before the "on" keyword have to be applied to
>     the specified type and are interpreted as "declare @type"
>   * The "extends" and "implements" clauses, if present, are to be
>     applied to the specified type and are interpreted as "declare parents"
>   * The ITDBlock will contain new methods and/or the second form of
>     the on keyword.
>
>
> The second form appear inside the ITDBlock of another "on" keyword.
>
> [<annotations>]
> on <MethodSig>|<FieldSig>|<ConstructorSig>;
>
>   * Annotations declared before the "on" keyword have to be applied to
>     the specified member and are interpreted as "declare @method" or
>     "declare @field" or "declare @constructor"
>   * Eventually, instead of signatures patterns could be used, given
>     that a complete signature is a specialized form of pattern.
>
>
> As you can see, this could be implemented as plain syntactical sugar, it could even be possible to write a set of regular expressions or a simple parser to convert from this new syntax to the current one.
>
> I'd love to try to code this inside AspectJ, and make this my first real code contribution to the project.
>
> WDYT?
>
> Simone
>
> --
> Simone Gianni            CEO Semeru s.r.l.           Apache Committer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

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

[Wim Deblauwe]

I like to add Spring's JMX annotations to my services using ITDs so I can look at the internals with the JConsole. I currently do this from an aspect with:

declare @type : MyServiceImpl : @ManagedResource( ...)

declare @method : public void MyServiceImpl.myMethod() : @ManagedOperation( ... )

I don't think it is hard to understand, but the proposal would indeed make it a bit shorter. However, using 'on' as a keyword seems a bit short and might be easily missed or read over I think.

regards,

Wim

2009/6/17 Andy Clement <andrew.clement@...>

Worth quoting the related enhancement request I think - Dave's musings
on thread http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg10106.html
gave rise to https://bugs.eclipse.org/bugs/show_bug.cgi?id=261728

Out of interest, why did you feel the need to use 'on' rather than
intertype?  Just because it is a shorter option? Did it mean something
different to you than 'intertype'?  Do you think intertype scares
users? 'on' to me perhaps suggests activities executing based on some
event occurring, rather than what we are trying to do here.

>From that bug report:

public aspect ITDAspect{
 intertype ITDInterface{
   public String value;
   public String getValue(){
     return value;
   }
   public void setValue(String value){
     this.value = value;
   }
 }
}


If I dig through that old thread, there are some issues that I should
have added to the bug report but haven't yet.  Things like:
- does this new syntax provide a way to ITD a static initializer?
- does this new syntax provide a way to ITD an inner class?

Changes to the ITD syntax would clearly benefit something like Spring
Roo which makes heavy heavy use of ITDs.  It uses so many that I think
we could probably noticeably improve the compile times for Roo
projects by changing syntax.

But something that thread had not touched upon, nor does the current
enhancement request - but you have touched upon today - is the
annotation of existing members:

  // Existing field
  @FieldLevelAnnotation
  on String name;

  // Existing method
  @MethodLevelAnnotation
  on void doThat();

  // Existing constructor
  @ConstructorAnnotation
  on MyOndBean(int);

I feel like there might be another even neater way to express this,
but I can't quite put my finger on what it is.  If the current is:

declare @field: String name: @FieldLevelAnnotation;

Above we have:

@FieldLevelAnnotation on String name;

mmmm,

@+FieldLevelAnnotation String name;

Not sure.

> As you can see, this could be implemented as plain syntactical sugar, it could even be possible to
> write a set of regular expressions or a simple parser to convert from this new syntax to the current one.

syntax sugar is definetly the way to go initially - but it is not at
all trivial due to the grammar changes (if making it a real language
feature of AspectJ instead of transforming new syntax to existing).  I
can already picture some enhancements to the weaving code in the face
of large scale ITD usage if we can move to something more like this
model.  Perhaps regexs are the way to get some users refactoring their
code to try this style out and validate the constructs - before diving
into the heavy lifting of changing the grammar.  But i'm not sure how
a regex approach would affect incremental compilation analysis.

Andy.

2009/6/16 Simone Gianni <simoneg@...>

>
> Hi all AspectJ users.
>
> There has been a discussion, about one year ago, about a simplified syntax for ITDs. The discussion then diverged in another thread about various ways of implementing ITD, which was not the original proposal made by Dave Whittaker.
>
> During one more year of heavy ITD usage in my Apache "Magma" Lab, I had time to think about it much deeper, and concluded that the original Dave's idea is quite right, but could even be improved.
>
> So I'm writing to ask your ideas and comments on what follows.
>
> The problem is that the current syntax that AspectJ use to alter the Java type system (ITDs, but also declare parents, declare @xxx etc..) is perfect if you are modifying a large number of classes. For example, all classes annotated with such and such will implement this interface.
>
> However, it is becoming more and more common the need to modify a single class, adding a few methods, or adding annotations to it. In fact annotations are becoming more and more important in Java programming, with lots of framework depending on them, and lots of JSRs being published to exploit annotations as much as possible. Having the ability to "add" annotation on a class on a separate aspect, which could be applied or not, is a very nice feature, but currently painful to obtain.
>
> Think for example of applying JSR-303 validation annotations or JPA ones on existing code using current syntax. Since annotations will be different for each field, it is quite a pain and quite unreadable. The power of patterns is, in these case, useless and counterproductive.
>
> Dave's case of declaring fields and methods on the interface then used in a declare parents, is a special and very common case of this situation.
>
> So, taking from Dave's proposal of introducing a new "intertype" keyword, I'd like to put the bar a little higher and propose the introduction of the "on" keyword. Please note that this syntax is not a complete alternative to the existing one, but is a complementary syntax for the described use cases.
>
> A simple example will give a quick idea of how it could work :
>
> public class MyOldBean {
>  private String name;
>  private String surname;
>
>  public MyOldBean(int i) { ... }
>
>  public void doThat() { ... }
> }
>
> public aspect RevampMyOldBean {
>  @ClassLevelAnnotation
>  on MyOldBean implements NewInterface {
>   // new field
>   @FieldLevelAnnotation
>   private String newField;
>
>   // new constructor
>   @ConstructorAnnotation
>   public MyOldBean(String _newfield) {
>      ...
>   }
>   // new method
>   @MethodLevelAnnotation
>   public String getNewField() {
>     ...
>   }
>
>   // Existing field
>   @FieldLevelAnnotation
>   on String name;
>
>   // Existing method
>   @MethodLevelAnnotation
>   on void doThat();
>
>   // Existing constructor
>   @ConstructorAnnotation
>   on MyOndBean(int);
>  }
>
>  // Dave's case
>  on NewInterface {
>   public void doThis() { ... }
>  }
>
> }
>
> If you think of how this has to be written with current syntax, you'll notice how less readable and more error prone it is. I'm not saying it will be necessarily "longer" in the sense of typing, except for Dave's case where there is an obvious reduction of typing, I'm thinking about readability and complexity more than mere number of keystrokes, but I'm pretty sure also number of keystrokes will be reduced.
>
> Moreover, refactoring methods from inside a class to an ITD aspect (or the opposite) would be a matter of cut and paste.
>
> I'm not a guru when it comes to formal language definition, but I think the "on" keyword could be defined like this :
>
> [<annotations>]
> on <Type> [extends <TypeList>][implements <TypeList>][ { <ITDBlock> }
>
>   * Annotations declared before the "on" keyword have to be applied to
>     the specified type and are interpreted as "declare @type"
>   * The "extends" and "implements" clauses, if present, are to be
>     applied to the specified type and are interpreted as "declare parents"
>   * The ITDBlock will contain new methods and/or the second form of
>     the on keyword.
>
>
> The second form appear inside the ITDBlock of another "on" keyword.
>
> [<annotations>]
> on <MethodSig>|<FieldSig>|<ConstructorSig>;
>
>   * Annotations declared before the "on" keyword have to be applied to
>     the specified member and are interpreted as "declare @method" or
>     "declare @field" or "declare @constructor"
>   * Eventually, instead of signatures patterns could be used, given
>     that a complete signature is a specialized form of pattern.
>
>
> As you can see, this could be implemented as plain syntactical sugar, it could even be possible to write a set of regular expressions or a simple parser to convert from this new syntax to the current one.
>
> I'd love to try to code this inside AspectJ, and make this my first real code contribution to the project.
>
> WDYT?
>
> Simone
>
> --
> Simone Gianni            CEO Semeru s.r.l.           Apache Committer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

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

[Dave Whittaker]

Hi Simone,

I agree that having an easier way to introduce annotations would be  
nice to have.  In my head I had always figured that a "code block" ITD  
would allow users to annotate the introduced members, but I hadn't  
considered using it to introduce annotations onto the target types  
themselves, or that it could be used to annotate pre-existing  
members.  I can see how that would be useful and allow a nice concise  
way of defining all your enhancements to a particular type in a single  
block of very java-like code.

As far as the keyword goes, I don't know if I have a preference one  
way or the other.  Intertype, on, mixin, within..... I think maybe  
mixin would be the most descriptive to a user with very little  
knowledge of AOP since that still pretty much describes me and it's  
how I've seen this type of introduction most commonly referred to, but  
they all seem pretty descriptive.  If "on" is used, maybe "declare on"  
would be more to the point and a bit more AspectJ like?

I think I'd probably also suggest that "extras" like static  
initializers and inner classes be avoided, at least at first.  I do  
think static initializers could be really cool at some point,  
especially if they had some access to the join point.  As a heavy user  
of the Seam framework I have about a bazillion classes that start like  
this:

@Name("someName")
public class SomeName{

        public static SomeName instance(){
                return (SomeName) Component.getInstance(SomeName.class);
        }

.....

}

So while I'd love to automate that in some way, I can live without it  
right now in the interest of keeping the complexity down and getting  
the new syntax ready for use quicker.

One thing I'd say about alternative syntax is that my first impression  
of this:

> @+FieldLevelAnnotation String name;

Was that it was referencing FieldLevelAnnotation and all of it's  
subclasses.... Of course you can't subclass an annotation and I may  
just be dyslexic, but it may also be a bit too much like the pointcut  
syntax I mistook it for.

On Jun 16, 2009, at 5:25 AM, Simone Gianni wrote:

> Hi all AspectJ users.
>
> There has been a discussion, about one year ago, about a simplified  
> syntax for ITDs. The discussion then diverged in another thread  
> about various ways of implementing ITD, which was not the original  
> proposal made by Dave Whittaker.
>
> During one more year of heavy ITD usage in my Apache "Magma" Lab, I  
> had time to think about it much deeper, and concluded that the  
> original Dave's idea is quite right, but could even be improved.
>
> So I'm writing to ask your ideas and comments on what follows.
>
> The problem is that the current syntax that AspectJ use to alter the  
> Java type system (ITDs, but also declare parents, declare @xxx  
> etc..) is perfect if you are modifying a large number of classes.  
> For example, all classes annotated with such and such will implement  
> this interface.
>
> However, it is becoming more and more common the need to modify a  
> single class, adding a few methods, or adding annotations to it. In  
> fact annotations are becoming more and more important in Java  
> programming, with lots of framework depending on them, and lots of  
> JSRs being published to exploit annotations as much as possible.  
> Having the ability to "add" annotation on a class on a separate  
> aspect, which could be applied or not, is a very nice feature, but  
> currently painful to obtain.
>
> Think for example of applying JSR-303 validation annotations or JPA  
> ones on existing code using current syntax. Since annotations will  
> be different for each field, it is quite a pain and quite  
> unreadable. The power of patterns is, in these case, useless and  
> counterproductive.
>
> Dave's case of declaring fields and methods on the interface then  
> used in a declare parents, is a special and very common case of this  
> situation.
>
> So, taking from Dave's proposal of introducing a new "intertype"  
> keyword, I'd like to put the bar a little higher and propose the  
> introduction of the "on" keyword. Please note that this syntax is  
> not a complete alternative to the existing one, but is a  
> complementary syntax for the described use cases.
>
> A simple example will give a quick idea of how it could work :
>
> public class MyOldBean {
> private String name;
> private String surname;
>
> public MyOldBean(int i) { ... }
>
> public void doThat() { ... }
> }
>
> public aspect RevampMyOldBean {
> @ClassLevelAnnotation
> on MyOldBean implements NewInterface {
>   // new field
>   @FieldLevelAnnotation
>   private String newField;
>
>   // new constructor
>   @ConstructorAnnotation
>   public MyOldBean(String _newfield) {
>      ...
>   }
>   // new method
>   @MethodLevelAnnotation
>   public String getNewField() {
>     ...
>   }
>
>   // Existing field
>   @FieldLevelAnnotation
>   on String name;
>
>   // Existing method
>   @MethodLevelAnnotation
>   on void doThat();
>
>   // Existing constructor
>   @ConstructorAnnotation
>   on MyOndBean(int);
> }
>
> // Dave's case
> on NewInterface {
>   public void doThis() { ... }
> }
>
> }
>
> If you think of how this has to be written with current syntax,  
> you'll notice how less readable and more error prone it is. I'm not  
> saying it will be necessarily "longer" in the sense of typing,  
> except for Dave's case where there is an obvious reduction of  
> typing, I'm thinking about readability and complexity more than mere  
> number of keystrokes, but I'm pretty sure also number of keystrokes  
> will be reduced.
>
> Moreover, refactoring methods from inside a class to an ITD aspect  
> (or the opposite) would be a matter of cut and paste.
>
> I'm not a guru when it comes to formal language definition, but I  
> think the "on" keyword could be defined like this :
>
> [<annotations>]
> on <Type> [extends <TypeList>][implements <TypeList>][ { <ITDBlock> }
>
>   * Annotations declared before the "on" keyword have to be applied to
>     the specified type and are interpreted as "declare @type"
>   * The "extends" and "implements" clauses, if present, are to be
>     applied to the specified type and are interpreted as "declare  
> parents"
>   * The ITDBlock will contain new methods and/or the second form of
>     the on keyword.
>
>
> The second form appear inside the ITDBlock of another "on" keyword.
>
> [<annotations>]
> on <MethodSig>|<FieldSig>|<ConstructorSig>;
>
>   * Annotations declared before the "on" keyword have to be applied to
>     the specified member and are interpreted as "declare @method" or
>     "declare @field" or "declare @constructor"
>   * Eventually, instead of signatures patterns could be used, given
>     that a complete signature is a specialized form of pattern.
>
>
> As you can see, this could be implemented as plain syntactical  
> sugar, it could even be possible to write a set of regular  
> expressions or a simple parser to convert from this new syntax to  
> the current one.
>
> I'd love to try to code this inside AspectJ, and make this my first  
> real code contribution to the project.
>
> WDYT?
>
> Simone
>
> --
> Simone Gianni            CEO Semeru s.r.l.           Apache Committer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

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

[Simone Gianni-2]

Hi Andy, Dave and Wim,
thanks for taking the time to read and comment my proposal.

I'll try to answer inline to all of you :

Dave Whittaker wrote:

> Hi Simone,
>
> I agree that having an easier way to introduce annotations would be
> nice to have.  In my head I had always figured that a "code block" ITD
> would allow users to annotate the introduced members, but I hadn't
> considered using it to introduce annotations onto the target types
> themselves, or that it could be used to annotate pre-existing
> members.  I can see how that would be useful and allow a nice concise
> way of defining all your enhancements to a particular type in a single
> block of very java-like code.

Yeah, right now AspectJ already carries annotations on an ITD method or
field, and at the same time offers a way to add new annotations to a
massive group of classes/fields, which is nice. Reading your
enhancement, I just evaluated the possibility of grouping together all
the ITD and annotation introduction syntaxes in a single one.

> If I dig through that old thread, there are some issues that I should
> have added to the bug report but haven't yet.  Things like:
> - does this new syntax provide a way to ITD a static initializer?
> - does this new syntax provide a way to ITD an inner class?

> I think I'd probably also suggest that "extras" like static
> initializers and inner classes be avoided, at least at first.  I do
> think static initializers could be really cool at some point,
> especially if they had some access to the join point.  
Same here, I'm not searching new features, those can be added later, but
a way to leverage the composition abilities of AspectJ to the average
user, without having him to know how to write AspectJ
class/method/constructor patterns, but using something as nearest as
possible to java syntax.

With the emerging of new technologies based on annotations, I see the
"annotation composition" ability of AspectJ as a nice feature, which
permits legacy or third party code integration with newer frameworks
while still encapsulating this migration as a different concern.

 > using 'on' as a keyword seems a bit short and might be easily missed
or read over I think.

 > Out of interest, why did you feel the need to use 'on' rather than
intertype?  Just because it is a shorter option? Did it mean something
different to you than 'intertype'? Do you think intertype scares users?
'on' to me perhaps suggests activities executing based on some event
occurring, rather than what we are trying to do here.

I agree with you both, we could use any kind of keyword, "intertype"
applies to the first usage (ITD on a class) not on the second usage
(annotate existing members), "on", "with", "declare .... on", "add ...
to" all seems good to me. I'd keep it on plain old English words and
avoid too academic terms.

I can remember some languages using "with" or "on" to simplify the
syntax in case of multiple calls to the same object instance, but I
can't remember which ones.

with (user) { setName("Simone"); setSurname("Gianni") } .. was it visual
basic? I think I "borrowed" the idea from there.

> Changes to the ITD syntax would clearly benefit something like Spring
> Roo which makes heavy heavy use of ITDs.  It uses so many that I think
> we could probably noticeably improve the compile times for Roo
> projects by changing syntax.


And the Apache Magma Lab too, that uses them in a very similar way ;D

The new syntax Dave and Me are proposing removes the use of patterns for
the specific case where you are annotating or "intertyping" a single
class, thus could improve the compile time probably. Yet, I'd start with
a modification of the parser but not the compiler, cause that
optimization could be expensive to realize and looking if/how users
adopt the new syntax before digging into the compiler optimization is
probably better.

> syntax sugar is definetly the way to go initially - but it is not at
> all trivial due to the grammar changes (if making it a real language
> feature of AspectJ instead of transforming new syntax to existing).  I
> can already picture some enhancements to the weaving code in the face
> of large scale ITD usage if we can move to something more like this
> model.  Perhaps regexs are the way to get some users refactoring their
> code to try this style out and validate the constructs - before diving
> into the heavy lifting of changing the grammar.

Yeah, you said it perfectly.

> But i'm not sure how a regex approach would affect incremental compilation analysis.

I don't know the answer :D .. but probably it could depend on when the syntax is converted from new syntax to old, if in ram after modification timestamp checks on the source or in some other way.

> Above we have:
> @FieldLevelAnnotation on String name;
> mmmm,
> @+FieldLevelAnnotation String name;

Yes, nice .. also if a single "+" to differentiate between introduction
of a new member and annotation of an existing one ... well, "on" is just
two chars so is the same :D


Thanks again for taking the time,

Simone

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

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

[Ichthyostega]

Simone Gianni schrieb:
> I agree with you both, we could use any kind of keyword, "intertype" applies
> to the first usage (ITD on a class) not on the second usage (annotate
> existing members), "on", "with", "declare .... on", "add ... to" all seems
> good to me. I'd keep it on plain old English words and avoid too academic
> terms.


Hi Simone,

just wanted to say, as a (rather) power user of AspectJ, I especially
liked the keyword "on". To me it communicates the meaning very clearly
in almost natural language.

I often found parts of the AspectJ syntax to be a source for "alienation"
and repudiation by java developers stumbling rather accidentally over
the use of Aspects, maybe because it is uses in a project they are
connected to in some manner. There is often the sensation that
"black magic" is going on which takes away control from the
developer.

I think, a syntax that is almost java but at the same time communicates
what is going on will be very helpful. Interestingly, for the initial
situation of just introducing a single member field, the original
AspectJ syntax fulfils this requirement. Just when introducing a
bulk of members and especially when combined with annotations,
things start to get confusing for the accidental reader.

Regards
Hermann V.

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