[JSR308] Implicit annotations with values

[Artemus Harper]

>
> The first mechanism is enabled by default to all checkers.  A type argument
> in a parameterized type can be an annotated type.  At first look it seems to
> me that this suffices to solve the problem with List.add and List.get
> situations.
> I don't know much about the subtyping relations for Unique (i.e. I would
> use three qualifiers: Unique, Aliased, PossiblyUnique - which is the root
> qualifier); so I would give examples of the Interned type system:
> internedString and nonInternedString have the obvious declaration


I originally had the annotations on polymorphic types, but this proved to be
problematic since a type may have not have generic parameters, or if it
does, it may need to qualify some of them from other ones. Although this is
sufficient to solve the type systems by simply having enough generic
parameters, it may force generic parameters where none are needed.

E.g.
If I create a class:
public class StringList extends List<String>
{
 ...
}

I have no way in this class of denoting that the element type, String, is
unique or not.

In order to follow your system I would need to add a generic parameter:

public class StringList<S extends @UniqueQ String> extends List<@UniqueQ
String> //@UniqueQ would be "possibly unique"
{
 ...
}

This problem with this is that I would like very much that users of APIs
that don't care about uniqueness and don't use APIs that care about
uniqueness need not add any annotations (or other decorations) and can still
use the same classes as those that do care. And although StringList could be
left as raw, this would only cause problems where some of the generic
information is necessary.

Another problem I have is that generics as they currently stand discourage
have many parameters, since it is cumbersome to keep track of references
that have many. So these are simply omitted for more trivial properties of
an object. Ideally every property (getter/setter) could be generic. E.g.
JList could be generic on its model: JList<Model extends ListModel>, so that
if you get the list model from the list you don't have to cast it to your
list model (or even DefaultListModel) to access special methods (such as
mutators). But this could be extended to all properties, such as the
ListCellRenderer and cell types. In that you would end up with:
public class JList<Cell, Model extends ListModel<? extends Cell>. Renderer
extends ListCellRenderer<? super Cell>>{...}
And this only has 3, more complex types might have more. This adds a lot of
static checks if you plan to have a custom ListModel, Cell type, and
ListCellRenderer, but is not necessary for most users that never access the
ListModel or the ListCellRenderer.

Also regarding the use of multiple copies of the same annotation, could
those be used as an alternative form for a single annotation?

E.g.
@A("1") @A("2")
Is the same as:
@A({"1","2"})

With the rule being that you could substitute a non-array for an array
element, so long as all copies have the same value for any non-array
elements.

E.g.
@interface A {
   String a();
   String[] b();
}

you could have:
@A(a="1","b="2")
@A(a="1",b="3")
but not:
@A(a="1",b="2")
@A(a="3",b="4")

Since an array is often used to simulate the possibility of having multiple
annotations of the same type on an element.



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