[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Revamping simplified ITD syntax
|
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
