[
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/
