[JSR308] Can we agree on our goals? (annotations on blocks)
Trevor Harmon
trevor at vocaro.com
Thu Feb 1 21:22:46 EST 2007
On Feb 1, 2007, at 5:11 PM, Tom Ball wrote:
>>> While I'm at it, Tom's suggestion of annotating only blocks would
>>> be acceptable for our purposes in JML.
>> Acceptable, yes, but annotating loops by artificially surrounding
>> them with braces feels kinda icky, doesn't it? It seems like a
>> compromise that just pushes extra work onto annotation users in
>> order to make implementation easier for us. Instead, we should try
>> to make using annotations as easy and natural as possible without
>> relying on new syntactical idioms.
>
> What new syntax?
Not a new syntax, a new idiom on using existing syntax.
> You always could put extra blocks around any statement or list of
> statements.
Right, but we shouldn't implement loop annotations that way (unless
we truly have to). For example, annotations on inner classes can be
added directly onto the declaration:
class Test {
@SuppressWarnings("unchecked")
class foo {}
}
Now, I suppose the designers of Java 5 annotations could have chosen
this approach instead:
class Test {
@SuppressWarnings("unchecked")
{
class foo {}
}
}
But I'm glad they didn't because the first approach is pretty clean,
the second one...not so much. I believe the first approach is what
users strongly prefer, and the same would also be true for loops.
Users won't want to have to put blocks around all loops just to be
able to annotate them for a WCET analysis tool. It adds extra work
and extra curly brackets that make the code less readable.
> Think of it as being similar to a synchronized block, but without
> impacting code.
Synchronized blocks are different. You're defining a block where one
didn't exist before. But with loops, the block is already defined, so
there shouldn't be any reason (from a user's perspective) to add a
block around a loop.
Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20070201/ae439e7e/attachment.htm
More information about the JSR308
mailing list