[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Revamping simplified ITD syntax

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/