generic List traversal and VT/VO compatibility

[Thomas W]

Thanks Vitaly, I was trying to make the point about "List<reftype> API
compatibility" for List<valtype>.

By the way, you can't add (Object) on wildcard collections today, so I was
> only responding to your proposal verbatim.  It does, however, allow null so
> that would still be an issue.


You are correct, there should be no add(Object). remove(Object) would be an
alternative method to illustrate the bridging, but that method brings up
the separate (solveable) issue of name-collisions.

My point is really about compatibility & assignability of List<int> to
List<?>;   not by it being a subtype, but by a "specializes/generalizes"
relation. I think it's important to keep that distinction clear.

So, my questions are:
- can existing method selection/ despatch allow this, or be tweaked/
enhanced to efficiently do so?
- can cast/ checkcast efficiently check a "specializes" relation also?

--------
To fix up my previous example:

List<?> would declare:
    Object get (int index)
    void add (Object item)
    boolean removeItem (Object item)      // renamed for illustrative
purposes, to avoid name collision

List<int> would declare:
    int get (int index)
    void add (int item)
    boolean removeItem (int item)
and expose as bridges:
    Integer get (int index)                       // compatible with List<?
extends Object>
    void add (Integer item)
    boolean removeItem (Object item)

Interestingly, writing this brings up the point that bridge methods are
already present in reftyped generics;  bridging from a subtypes (with
different bounds) to superclass inherited methods.

Our circumstance here is a little different -- we want our List<int> to
include reftype API compatibility.


Regards,
Thomas