[JSR308] Enhanced for loops

[Mahmood Ali]

Hi Artemus,

I may need to re-examine your email further to understand some of its  
point.  However, it seems that the way you deal with type arguments is  
very different from our approach.


> The reason I choose not to directly annotate the type parameters  
> (and instead use InnerUnique) is that this would unnecessarly  
> require that some classes have a generic parameter for items that  
> did not need to have type parameters for.
Once a type is already a generic type (like in Iterator), I fail to  
see why you would need to use InnerUnique.

> In my test case I have:
>
>         //Create a list of unique elements
>         @InnerUnique({"T"}) UniqueList<String> list = new  
> UniqueList<String>();
>         @Unique String s1 = new String("s1"); //cannot get  
> references to string literals
>         list.add( (@Unique String) s1); //give up control of the  
> reference to the list
>         list.add(new String("s2")); //no cast needed here
>
>         @InnerUnique({"T"}) UniqueList<String> list2 = new  
> UniqueList<String>();
>         @InnerUnique({"T"}) Iterable<String> iterator =  
> list.drainToItr();
>         for(@Unique String s : iterator) //get an iterator that  
> removes elements from the list
>             list2.add((@Unique String) s); //add the unique  
> reference to another list
The types trouble me a bit.  '@InnerUnique({"T"}) List<String>' and  
'List<@Unique String>' has the same conceptual type, yet neither is a  
subtype of the other?!  The Checker Framework (as part of its  
syntactic style) was designed to support the latter ('List<@Unique  
String>').

> The UniqueList.add method looks like (where items is an  
> AtomicReferenceArray)
> public void add(@Unique({"T"}) T item) @NoEscape
> {
>         ensureCapasity(size + 1);
>         //We need to cast here to give ownership to the array. After  
> this statement
>         //item is no longer referencable in the normal manner.
>         items.set(size++, (@Unique({"T"}) T) item);
> }
>
> What @Unique({"T"}) means is that item is unique if this UniqueList  
> instance is declared as InnerUnique({"T"}). The callee doesn't know  
> if its elements are unique, only the caller knows.
Again, when there is already a parameterized type, why not use it?   
Why cannot the method simply be:

public void add(T item) @NoEscape
{
         ensureCapasity(size + 1);
         //We need to cast here to give ownership to the array. After  
this statement
         //item is no longer referencable in the normal manner.
         items.set(size++, (T) item);
}

In this case too, only the caller knows if its elements are unique or  
not.

> Some of the requirements I would like to keep for this project:
> 1. Reusability of code that will work for both annotated and  
> unannotated code.
>
> 2. User does not need to be aware of the annotations except in  
> situations that demand it.
>  -- For API utility classes, the classes can support uniqueness, but  
> all the methods are freely useable for non-unqiue instances.
If a user doesn't care about uniqueness, why would he be using the  
uniqueness checker?

Regards,
Mahmood

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20080805/414bc76f/attachment.htm