[Jsr308-statements] Re: [JSR308] Block Annotations Suggestion

[Eduardo Born]

Igor, Trevor,
that's right, and the usability is one of the reason why I proposed the
annotations on a block of statements.

In the case, I feel that makes the code dirtier to have several repetitions
of the same annotation to a group of elements, and that makes the code less
readable and maintainable too.

I think that having a way to apply an annotation not only to a single
statement, but to a group of them, would make the statement annotations much
more usable.

What if we had a situation were a single annotation needs to be applied to
several consecutive statements? In that case such syntax could make things
much more clear and easy to implement, although I agree that a block creates
a separated scope and that may be an inconvenient too bad to make it happen
on practice.

I made a research on the way that annotations are being proposed on block
statements, and the scope problem makes that unusable for the purpose I
suggested. I don't think changing the annotation block to something
different than a compound statement is something that would/should be
implemented.

Anyone feels that this is something that, regardless of the syntax adopted,
would be useful?

Cheers

Eduardo Born

2007/10/3, Igor Peshansky <igorp at us.ibm.com>:
>
>
> "Eduardo Born" <nosachamos at gmail.com> wrote:
>
> > Hi All!
> > My name is Eduardo Born, I'm new to the list, and I'm VERY interested
> > on discussing the future of Java Annotations.
> >
> > I have been working very close and deep with Java reflection and
> > annotations, and there are some things I miss in the current Java
> > Annotations implementation that are being currently proposed, and some
> > that are not, so I joined the list to make suggestion and help on the
> > current proposal discussions whenever possible.
> >
> > My first suggestion is to have a block annotation syntax, so a single
> > annotation can be applied to a group of elements. For example, let's
> > suppose we have a marker annotation that informs that a given field is
> > to be remotely accessible through a given framework, for example
> > @RemotelyAccessible.
> >
> > Currently, to make several fields marked as remotely accessible, we
> > would have to do the following:
> > ...
> > @RemotelyAcessible
> > private String field1;
> >
> > @RemotelyAcessible
> > private String field2;
> >
> > @RemotelyAcessible
> > private String field3;
> > ...
> >
> > and so on.
> >
> > Why not have a syntax like the following:
> >
> > @RemotelyAccessible {
> >      private String field1;
> >      private String field2;
> >      private String field3;
> > }
> >
> > So the given annotation is replicated to all declarations/elements
> > inside the block.
> >
> > As a senior Java developer, I frequently write my own annotations, and
> > that syntax would make my life easier. I hope that helps more folks too.
>
> >
> > What do you think?
> >
> > Cheers!
> > Eduardo Born
>
> Hi, Eduardo,
>
> There is a potential problem with your proposal.  Will the block be part
> of the annotation, or will it be a regular compound statement in Java?
> If the latter, the Java compiler will treat your block as a non-static
> initializer that declares some variables (similarly, if inside the method,
> the block will define its own scope, so the variables will not be visible
> outside).
> If the former, this is a digression from the current Java annotation
> syntax, and probably belongs on the jsr308-statements list, which deals with
> annotations on statements.
> In either case, how deep does your proposed annotation apply?  Suppose
> there is a block nested within the braces...  Will the annotation apply to
> the statements inside that block?
>
> I've Cc'd this to the jsr308-statements list.  Perhaps it would be best if
> this discussion were continued there.
>         Igor
> --
> Igor Peshansky  (note the spelling change!)
> IBM T.J. Watson Research Center
> XJ: No More Pain for XML's Gain (http://www.research.ibm.com/xj/)
> X10: Parallel Productivity and Performance (http://x10.sf.net/)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308-statements/attachments/20071003/fa20bdd6/attachment.html