[JSR308] Enhanced for loops

Artemus Harper subanark at gmail.com
Tue Aug 5 12:18:07 EDT 2008


> Once a type is already a generic type (like in Iterator), I fail to see why
> you would need to use InnerUnique.
>
Once a type is generic its generic parameters are fixed. It is incompatible
to add additional parameters to an already generic type. Generics can get
overboard:

JList<String, DefaultListModel<String>, DefaultCellEditor<String>,
DefaultListSelectionModel, DefaultListCellRenderer, ListUI>

what would all that "expressiveness" buy you? The first element would mean
that when you get the selected element you would not need to cast it. The
second element would mean that if you had a JList and wanted to edit you
would not need to cast the return value of getModel() to a type that is
editable. The others, only if you wanted to change some property of that
component. But... since the most common use of a JList is an uneditable one,
the first one is nice to have. The second one is not too uncommon to need,
and the others are downright rare. But with generics you can only choose one
selection of those, and that gets locked in.


> 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>').
>
Currently I ignore all annotations on type parameters. Previously I did have
the annotatinos as you have suggested.
But...
1. I would need 2 additional annotations: MaybeUnique and NotUnique. The
first would be needed to indicate that the class supports the Unique
annotation on its type, the second for cases where the method cannot be
executed for unique parameters.
2. As I noted before, the current generics syntax is too limiting for what I
want.


> If a user doesn't care about uniqueness, why would he be using the
> uniqueness checker?
>
Because they only care about uniqueness in a few special cases that may span
across a larger project. Only in the places that manadate it would it be
important. The rest of the project has the uniqueness checker used only to
ensure that none of the references from the part that requires uniqueness
escapes into the rest of the project (e.g. an unchecked call into a method
that requries a unique parameter).


-- 
Artemus Harper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20080805/3cf94a1d/attachment.htm 


More information about the JSR308 mailing list