« Return to Thread: Revamping simplified ITD syntax
Re: Revamping simplified ITD syntax
by Dave Whittaker
::
Rate this Message:
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
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
« Return to Thread: Revamping simplified ITD syntax
| Free embeddable forum powered by Nabble | Forum Help |
