Idea how to implement VT/VO compatibility in JVM
stef at epardaud.fr
Mon Jan 12 16:30:27 UTC 2015
On 01/12/2015 05:05 PM, Brian Goetz wrote:
> Part of what you may be missing is: code that was compiled with older
> compilers. While we have the opportunity to change the translation of
> newly compiled code, there will be existing code out there that we
> also need to be compatible with.
Well, these would call the boxed methods, that would be _more_
compatible since they can traverse collections of value types by boxing
>> To me the compromise that we can't write code that iterates say, a
>> list, without knowing at compile-time what type of value-generics it may
>> hold is a compromise that will haunt Java forever.
> This is just incorrect. You can write a generic method:
> <any T> forEach(Collection<T> c, Consumer<T> action)
But there's no instantiation of "any T" that would let me not know the
generic type at compile-time, no? Frameworks that need to traverse
collections without having to know what type of thing they're traversing
can't do that with value types ATM. Obviously with my proposal they'd
box, but at least they could traverse any collection.
>> This clearly doesn't work with fields, but so what? Add a language
>> limitation that
>> fields of Any-generic types must be private.
> Which means that any class that had public fields can't ever be
> anyfied. Also, as people become more aware of the evils of
> mutability, more people are (correctly) writing classes with public
> final fields rather than intermediating with unnecessary getters.
Well, do we have numbers on how many classes expose their state like
this via public fields? Does the Java collection API do that? Perhaps
you're right and it's unacceptable, but it's not really clear. I suppose
that one way to deal with this if this was an unacceptable limitation
would be to generate boxing specialised methods that could provide boxed
values for virtual fields backed by actual value fields.
> (Hint: when you're inclined to say "but so what", that's the warning
> sign that you're spiraling off into wishful-thinking territory.)
It's not about "so what" it's about the cost of the compromise. I happen
to find that tradeoff to be much much more acceptable than treating
List<Object> and List<@ValueType Date> disjoined. I do appreciate that
it's a matter of personal opinion and I may be in the minority, but I've
no evidence of that ;)
More information about the valhalla-dev