[JSR308] array-valued annotations
Ted Neward
ted at tedneward.com
Mon Jan 29 21:06:54 EST 2007
> @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?
One question I would like to raise, though, is that of
annotations-as-part-of-the-type-signature: we need to decide--and
quickly--whether this ...
@Readonly Document rodoc = ...;
Document doc = ...;
doc = rodoc; // legal?
rodoc = doc; // legal?
... is legal. My gut tells me it shouldn't be, but oh, does that open up a
HUGE can of worms a-la C++'s "const". Which then leaves us with "yes, both
are legal but generate a warning", which then implies (again) that
annotations applied at the local variable scope are not part of the type
signature.
Just out of curiosity, does anybody on the list have experience with DBC?
That kind of experience would seem to be helpful and appropriate here, since
we seem to be treading into that same space.
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
> -----Original Message-----
> From: jsr308-bounces at lists.csail.mit.edu [mailto:jsr308-
> bounces at lists.csail.mit.edu] On Behalf Of Pavel Krupets
> Sent: Monday, January 29, 2007 12:39 AM
> To: jsr308 at lists.csail.mit.edu
> Subject: RE: [JSR308] array-valued annotations
>
> Hello,
>
> IMHO
>
> Yep. The main point is that array itself is an object (no matter whether
> it's n-dimensional or array of arrays with different lengths {which I
> think is a side effect :=)}) and it contains objects with the specified
> type. So we have two entities to which annotations can be applied.
>
> I think if one needs 'strange' array (array of arrays with different
> dimensions and annotations) one can always use:
>
> @Readonly List<@Readonly @NonNull List<@Readonly @NonNull Document>> docs
> = ...
>
> This will keep ordinary arrays simple.
>
> P.S. "In protocol design, perfection has been reached not when there is
> nothing left to add, but when there is nothing left to take away." (c)
> RFC1925
>
> With regards,
> Pavel Krupets
> www.x-markets.db.com
> Deutsche Bank [/]
> +7 (495) 783-03-30
>
> > -----Original Message-----
> > From: Ted Neward [mailto:ted at tedneward.com]
> > Sent: Sunday, January 28, 2007 6:10 AM
> > To: 'Gary T. Leavens'; Pavel Krupets
> > Cc: jsr308 at lists.csail.mit.edu
> > Subject: RE: [JSR308] array-valued annotations
> >
> > I think I see Pavel's point, though; the declaration "doc" implicitly
> > suggests that all of the dimensions to the "jagged" array behind the
> > reference are of the same type (Document). I can't declare the different
> > dimensions to be of different types, a la:
> >
> > Document[Object[]] doc = ...
> >
> > Meaning, a single dimenion of Document objects each of which in turn are
> > also references to Object arrays. (Makes no sense!)
> >
> > If annotations are to be considered part of the type's signature (which
> is
> > WAAAAY beyond what we designed or had in mind), then Pavel's right, a
> > multidimensional array has to contain all the same type, regardless of
> the
> > number of dimensions.
> >
> > Ted Neward
> > Java, .NET, XML Services
> > Consulting, Teaching, Speaking, Writing
> > http://www.tedneward.com
> >
> >
> > > -----Original Message-----
> > > From: jsr308-bounces at lists.csail.mit.edu [mailto:jsr308-
> > > bounces at lists.csail.mit.edu] On Behalf Of Gary T. Leavens
> > > Sent: Thursday, January 25, 2007 9:48 AM
> > > To: Pavel Krupets
> > > Cc: jsr308 at lists.csail.mit.edu
> > > Subject: Re: [JSR308] array-valued annotations
> > >
> > > Hi Pavel and all,
> > >
> > > On Thu, 25 Jan 2007, Pavel Krupets wrote:
> > >
> > > > Hello,
> > > >
> > > > I don't think it's appropriate to use annotations like:
> > > > "Document[][@Readonly]". What I mean is that there is no much sense
> in
> > > > specifying different annotations for different dimensions of the
> > array.
> > > If
> > > > such behavior is needed other types can be used (like List<...>,
> etc).
> > I
> > > > think annotations should be used only with:
> > > >
> > > > - array as an object (like: @NonNull @Readonly Document[][] doc =
> ...)
> > > > - objects which are stored inside arrays (like: Document @NonNull
> > > > @Readonly [][] doc = ...)
> > > >
> > > > The reason behind this is that array (one or multi-dimensional) is
> an
> > > > 'atomic' type which has type of stored object and dimensions. Just
> > want
> > > to
> > > > keep things simple.
> > >
> > > I agree that keeping things simple is good when possible. But
> > > semantically, each array declared is itself a location which holds a
> > > collection of locations. Thus, to simplify to one dimension:
> > >
> > > Document[] docs;
> > >
> > > could look like
> > >
> > > 0 1 2 3
> > > docs [ *-]------> [ | | | ]
> > >
> > > and the location named doc can be null or readonly independent of the
> > > locations doc[0]..doc[3]. The same holds for readonly.
> > >
> > > You would lose expressiveness if you can't independently talk about
> > > these different locations.
> > >
> > > 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
> > >
> > >
> > > _______________________________________________
> > > JSR308 mailing list
> > > JSR308 at lists.csail.mit.edu
> > > https://lists.csail.mit.edu/mailman/listinfo/jsr308
> > >
> > > --
> > > No virus found in this incoming message.
> > > Checked by AVG Free Edition.
> > > Version: 7.5.432 / Virus Database: 268.17.11/652 - Release Date:
> > 1/25/2007
> > > 3:32 PM
> > >
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.17.12/653 - Release Date:
> 1/26/2007
> > 11:11 AM
> >
>
>
> ---
>
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.12/655 - Release Date: 1/28/2007
> 1:12 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