Annotations for language features
Artur Biesiadowski
abies at adres.pl
Sun Aug 16 11:23:18 PDT 2009
Reinier Zwitserloot wrote:
>
> Sure, no annotations in the core java libraries actually create
> generated source files, but the ability to generate files clearly
> isn't an afterthought; it's a very valuable part of the annotation system.
There is a difference between generating additional code from
annotations (like many remote invocation wrappers do) and actually
changing what the code containing the annotations does.
I think it is a matter of taste. For me the line is somewhere between
having annotation
@NonNegative int x;
which gives annotation-aware compiler right to reject/warn on certain
assignments, versus
@Unsigned int x;
which would mean that this int is treated as real unsigned integer on
all comparisons/shifts/etc (maybe even using different set of bytecodes
in future jvm). Same way, for me
@Property int x;
would be acceptable as a kind of marker for compiler which would reject
source file if it doesn't contain properly constructed getters and
setters, but not as something which silently generates missing methods.
You asked for the reasons and I must say that I'm in trouble to find any
hard ones. I think that for me main thing is to avoid 'hackery' in
language because of compatibility reasons only. There is considerable
hackery in implementation already (private field/method accesors from
inner classes, generics erasure) - but whatever you can say about
generics, they got implemented as Map<String,Something> x; instead of
@Map(String.class,Something.class) Map x; I feel that language
extensions should be kept this way - even if it is costly in term on
compiler support.
> > Next step and we will end up Borland
> > Pascal way and put control instructions in comments/javadoc.
>
> That's a logical fallacy.
It might look like one, but I have already been through that when
discussing Design By Contract support in java long time ago. Take a look at
http://www.mmsindia.com/DBCForJava.html
for example for a solution which takes this route. Today, with
annotations, we probably won't actually end up back in javadoc code
generation camp, but this was more a mindset rather than particular
solution I was referring to.
With best regards,
Artur Biesiadowski
More information about the coin-dev
mailing list