[JSR308] array-valued annotations

[Ted Neward]

> Thanks. :-)
> 
You're welcome. :-)

> 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.
> 
Oh, agreed; I'm not arguing against that aspect of your point. Case in
point, I think we can go a fair distance towards making the language safer
and easier to use with these annotations, which in turn justifies the added
complexity (to a point).

What I do want to worry about, though, is the idea that we keep a realistic
eye towards what we're really creating with this. Pavel's example just
really caught me up short as to just how bad "annotation hell" can be in a
single declaration, hence my expressed desire to try to avoid making things
worse. :-)

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 11:55 PM
> To: Ted Neward
> Cc: jsr308 at lists.csail.mit.edu
> Subject: RE: [JSR308] array-valued annotations
> 
> 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
> 
> 
> --
> 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