Idea how to implement VT/VO compatibility in JVM

[Vitaly Davidovich]

But List<value> is not and cannot be List<Object> - I'm guessing you mean
List<?>.

sent from my phone
On Jan 22, 2015 8:59 AM, "Stephen Colebourne" <scolebourne at joda.org> wrote:

> On 22 January 2015 at 13:26, Stéphane Épardaud <stef at epardaud.fr> wrote:
> > You can see that at compile-time I don't have any idea about which value
> > types I could encounter, so the only instantiation of `T` I will have is
> > `Object`, never `value Date` which may pop up there, and since (unboxed)
> > value types don't have any common superclass I can't traverse
> collections of
> > them without knowing at compile-time what type they are. Which is not
> > possible for frameworks.
>
> Stephane is making a key point that is critical to the success of
> value types as a project. Almost every piece of framework logic that
> navigates around an arbitrary object structure will have code that
> queries if an object is a Collection/Map and performs specific
> processing, for example:
>
> https://github.com/JodaOrg/joda-beans/blob/master/src/main/java/org/joda/beans/ser/SerIteratorFactory.java#L77
>
> https://github.com/JodaOrg/joda-beans/blob/master/src/main/java/org/joda/beans/ser/xml/JodaBeanXmlWriter.java#L176
>
> I'm sure its easy to find other examples in similar projects. Note
> that this is a key problem to the Beans v2.0 MetaModel stuff I've been
> looking at.
>
> It seems necessary to make List<value> is in some way related to
> List<Object>, just like a value can be boxed to an object. Doing so
> should take existing libraries that accept Collection<?> and loop over
> it, and allow them to accept Collection<value>. It seems to me that
> anything else is token backward compatibility, rather than real
> backwards compatibility. As indicated in other messages, you don't
> always know what T is at compile time.
>
> Stephen
>