[JSR308] array-valued annotations

[Gary T. Leavens]

Hi Ted,

Thanks. :-)

I am all for linguistic simplicity too.  I would just like to keep the
arguments focused on what good programs we can write with the simplest
language.  I don't think we can do much about the bad programs, they
will always be there.

On Mon, 29 Jan 2007, Ted Neward wrote:

> Does that include RPN?
>
> OK, levity aside, with all due respect to Flon, if we can avoid complexity
> and pursue a policy of linguistic simplicity except where absolutely
> necessary, I think we'll make the language more palatable for the
> programmers who end up having to use it in day-to-day affairs.
>
> Or, perhaps worded differently, "We should not now, nor should we ever,
> pursue changes to the programming language that will make it the least bit
> easier to write bad programs."
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>
>
>> -----Original Message-----
>> From: Gary T. Leavens [mailto:leavens at cs.iastate.edu]
>> Sent: Monday, January 29, 2007 7:53 PM
>> To: Ted Neward
>> Cc: jsr308 at lists.csail.mit.edu
>> Subject: RE: [JSR308] array-valued annotations
>>
>> 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
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.432 / Virus Database: 268.17.14/658 - Release Date: 1/29/2007
>> 2:49 PM
>>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.14/658 - Release Date: 1/29/2007
> 2:49 PM
>
>


         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