generic List traversal and VT/VO compatibility

[Vitaly Davidovich]

You could possibly make List<?> work as List<any T> for readonly cases
(iteration), with the performance cost of boxing.  But having add (Object)
on it is just not cool - that implies you can add any type, including null
(provided the List implementation allows for it), but clearly you'll get a
runtime exception.  When it comes to reified generics, I don't expect such
runtime exceptions if my code compiles.  This may also break some existing
code that makes these assumptions.  The fundamental problem is that List<?>
implicitly assumes erased generics and that the erasure is a reference type
(i.e. null is valid).

sent from my phone
On Jan 25, 2015 10:00 PM, "Thomas W" <twhitmore.nz at gmail.com> wrote:

> 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
>
>