Clarification on migration to value types and boxed vs unboxed representations
peter.levart at gmail.com
Tue Jan 6 07:56:15 UTC 2015
On 01/06/2015 03:15 AM, Brian Goetz wrote:
>> Obviously I may have missed some explanation in which case apologies but
>> I'd just like to clarify the situation with respect to migrating
>> value-like classes to value types. So let's suppose I've got a class
>> take java.time.LocalDate as an example) which morally should be a value
>> type but isn't because the class predates the language feature. Its
>> it isn't serializable or defines a serialization delegates, all its
>> are final, the class is immutable. Looks like a great candidate to be
>> converted into a value type and the preconditions seem to apply.
> This what we call a /value-based/ class.
> The question is, I believe, will it possible to (compatibly) migrate a
> class that was a value-based reference class into a value type. We
> certainly hope so, but we don't yet have a story for this, as I
> mentioned the other day.
> As John pointed out, we're pretty comfortable with the consequences
> for synchronization (both the 310 classes an Optional refer to the
> value-based disclaimer, which says "do this and you'll be sorry.")
> The hard part about this migration compatibility is: nullability.
> (This is where someone repeats the usual commercial for null-safe
> types and/or elvii operators.) While null truly makes no sense for
> Optional, and I could imagine being willing to hose code that relies
> on Optionals being null, this is probably the exception among known
> value-based classes (e.g., LocalDate). So while we may have a
> migration story for libraries that dispense and receive
> formerly-value-based value types, we don't have a story for migrating
> client code that might expect nullability for those types.
Perhaps to accommodate gradual (opt-in for uses not for declarations)
migration path, denoting the name of a class representing value type
could still mean the "box" of it and denoting the actual value type
would use special syntax.
> (As to the timing of boxing and unboxing, it would be exactly as
> primitives today.)
More information about the valhalla-dev