[JSR308] array-valued annotations
Ted Neward
ted at tedneward.com
Tue Jan 30 02:44:42 EST 2007
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
More information about the JSR308
mailing list