generic List traversal and VT/VO compatibility

[Vitaly Davidovich]

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.

sent from my phone
On Jan 25, 2015 10:15 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

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