generic List traversal and VT/VO compatibility

[Thomas W]

Hi Stephane, Stephen, Vitaly,

The issue at hand (in this thread) is about iterating over opaque lists (or
> any iterable, for that matter).  The crux of the issue is that what fits
> most naturally with any-fied generics, <any T> void iterate(List<T> ...),
> is today being written using List<?>.  And one of the (predominant?)
> reasons that's used today is because of late-binding/reflection where the T
> isn't known at compile time.  I don't think anyone is claiming there's any
> subtype relationship between List<int> and List<?> from an OO perspective.
>

I am not fully clear why we can't fit "reasonable" generic traversal &
processing of List<int>/ List<value>into the existing language scheme.

We can fairly consider an interface "List<? extends Object>" to mean _a
List of items coercable to Object._  As an interface, this merely specifies
that the Items can be accessed via an "Object" reftype API.

This is perfectly possible for List<int> to implement -- primitives &
value-types can (and for generality, should) offer a boxed API. This gives
general iteration/ compatibility "for free", out of the box. Internally
bridge methods would be used.

When we write specific type-code against List<int> or List<valuetype>,
these would still be nominally compatible with List<?> but the more
efficient type-specific methods would be bound.

So efficiency would be highest for type-specific code, but generality would
be be preserved via List<?> including all List<primitive>, List<valtype>.
Efficiency of generic iteration of primitive/ valtype would be similar to
today's boxed lists.

An important point on types & type relations:
- There should presumably be some relationship in the type system between
List<int> and List<?>.
- This is not a proper "supertype/subtype" relationship. List<int> is a
narrowing of List<?>, rather than a real subtype.
- We could consider it as a "specializes" or "reifies/generalizes"
relation.
- We should not try to treat/ or consider this relation as something it is
not, as our conclusions/ results may likely be incorrect. (in regard of
design)

I can still imagine updating the language, such that List<?> now
effectively meant "List<any>". Boxing would be automatic and implicit to
fill in the gaps. Some improvement to method-selection & despatch rules
might be required.

So:  "<?>"  would now mean "<any cooercable to Object>".

List<?> would declare:
    Object get (int index)
    void add (Object item)

List<int> would declare:
    int get (int index)
    void add (int item)
and expose as bridges:
    Object get (int index)
    void add (Object item)

Existing framework code should almost totally "just work" -- with similar
performance to today -- via the boxed APIs. Hopefully, having clear &
meaningful "specializes/generalizes" type relation would help framework
code in future to do even better.

Question:  can Java method despatch be tweaked/ enhanced to achieve the
above?
----------

Last point: Interface "compatibility" may conceivably be easier/ more
possible, than the same thing for classes. I don't know if this a solid
conclusion or just instinct, prompted by two things:
- the avoidance of concrete class implementation inheritance (T[] elements),
- greater flexibility of interface method-dispatch.

For this reason I am proposing the relation for interface types, as a
starting point.


Regards
Thomas Whitmore