[JSR308] array-valued annotations

[Joseph Kiniry]

Hi Ted et al,

Thank you all for these quality initial discussions.  It is nice to  
see new perspectives and hear new voices on these issues.

On 28 Jan, 2007, at 3:09, Ted Neward wrote:

> 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 presume you mean all the values, not all the dimensions.

> 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!)

Correct.  But using this notation,
   Document [][] doc
means
   Document [Document[]] doc

And we find that, unfortunately, Java programmers like to sometimes  
make the outer Document[] type different than the inner Document[];  
i.e., one might permit null elements and one might not.

To me, supporting type annotations in Java means supporting  
annotating *all* of the types one can declare in Java, not just some  
of them.

> 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.

Doesn't this represent a fairly conservative view of what constitutes  
a type?  I certainly consider such annotations as part of the type  
signature.

Indeed, as reiterated above, a multi-dimensional array does contain  
only a single value type.  Unfortunately, such arrays in Java are  
decomposed into more than just their data values.  Consequently,  
those of us that must write rich type annotations on such arrays in  
"real" software frequently see situations like those mentioned  
earlier by John and Gary.

While perhaps we'd like to say the use of types like these represent  
a bad practice in software design, as emphasized by Tom, they are  
actually fairly common, and thus we need to be able to describe them  
precisely, preferably in a manner that is easily understood by Java  
developers.

Joe
---
Joseph Kiniry
School of Computer Science and Informatics
University College Dublin
http://secure.ucd.ie/
http://srg.cs.ucd.ie/

> 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