[JSR308] array-valued annotations

Gary T. Leavens leavens at cs.iastate.edu
Mon Jan 29 22:52:33 EST 2007


Hi Ted and all,

Relative to your example below, I would refer you to "Flon's Axiom"

          "There does not now, nor will there ever, exist a
           programming language in which it is the least bit
           hard to write bad programs."

(ACM SIGPLAN Notices, volume 10, number 10, Oct 1975, pages 16-17.
http://doi.acm.org/10.1145/987253.987256
Read it, it's very short, and quite worthwhile for such discussions.)

Flon's point is that it's invalid to argue that: here's an example in
language X that is really bad, therefore language X is really bad.
Applied to the present discussion, I would say that it's invalid as an
argument to say that if the syntax makes some very hard to understand
example possible, then it's invalid.  Such examples are a natural
outgrowth of the nesting of context free grammars and the limits of
human language processing abilities.

Put more positively, we should look to see if the syntax can say what
we want to say and what tools need.

         Gary T. Leavens
         Department of Computer Science, Iowa State University
         229 Atanasoff Hall, Ames, Iowa 50011-1041 USA
         http://www.cs.iastate.edu/~leavens  phone: +1-515-294-1580

On Mon, 29 Jan 2007, Ted Neward wrote:

>> @Readonly List<@Readonly @NonNull List<@Readonly @NonNull Document>> docs
>> = ...
>>
> Oh, man, reading that made my head hurt. Without color syntax highlighting,
> we are seriously flirting with an unreadable language. I, for one, propose a
> high-priority goal of the JSR to be the absolute minimum amount of verbage
> necessary to express a concept through an annotation--if Pavel had decided
> to add @Threadsafe to each of those Lists, we'd have a two-line,
> 160-character *variable declaration*. That's going to fire up *everybody*'s
> accusations of Java being too complex.
>
> Much of that complexity would go away if Java introduced a typedef-like
> syntax, so that I could write:
>
> typedef ROList<T> @Readonly List<T>;
> typedef RONNList<T> @Readonly @NonNull List<T>;
> typedef RONNDocument @Readonly @NonNull Document;
>
> ROList<RONNList<RONNDocument>> docs = ...;
>
> which would seem to be a tad easier to read. That's outside of this JSR's
> scope, granted, but a worthwhile recommendation to the poor guy maintaining
> javac these days. (Anybody want to hack on JDK 7 today? :-) )
>
> Meanwhile, if somebody *really* wants a multidimensional array to have
> differing characteristics along the dimensions, why can't they do something
> along the lines of...
>
> @Readonly Document[][] docs = {
> 	new @Readonly @NonNull Document[] {
> 		new @Readonly @NonNull @Threadsafe Document(), ...
> 	},
> 	new @Readonly @NonNull Document[] { ... }
> };
>
> It's not concise, but I think this is going to be one of those cases that
> falls on the short side of the 80/20 rule, and so as long as there's a way
> for a programmer to do it (in those odd cases when they need to), I don't
> think it's worth spending a lot more time on it.
>
> This also raises a question of inference, though: how far does the use of
> the annotation spread in a multidimensional array? In the declaration ...
>
> @Readonly Document[][] docs = ...;
>
> ... is just the "docs" reference @Readonly, or is every reference inside the
> array's multiple dimensions also assumed to be @Readonly? It would seem to
> me to be more in keeping with Java's existing style to assume that only the
> "docs" reference is @Readonly (just as "new" only applies to the array
> itself, not its contents), but one could argue that "@Readonly" is a
> modifier to "Document", and therefore the array brackets are simply applying
> that modifier to each dimension. In other words,
>
> @Readonly Document[][] docs = ...;
>
> ... is an array of @Readonly Document[] references, which are in turn arrays
> of @Readonly Document references. Thoughts?
>
> ...
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com





More information about the JSR308 mailing list