Value types - compatibility with existing “value objects”

[Peter Levart]

On 01/08/2015 07:35 PM, Brian Goetz wrote:
>> Regarding “Value types” seem to assume that you will use it just for
>> small types and you will implement bigger types as objects (with
>> different syntax)."...
>
> There seem to be a lot of mis-assumptions on this topic.  There is no 
> arbitrary limit on the size of a value type (other than existing 
> classfile limitations such as constant pool size). However, many of 
> the performance benefits of value types drop off when you get beyond a 
> handful or two of components.  This is why we say the "sweet spot" is 
> things like numerics, small-ish tuples, or algebraic data types.  But 
> there's no "it stops working beyond" point that you are forced to 
> switch to, (and where there are visible performance differences will 
> be a function of hardware and time, just like cache effects are today.)
>
>> Value types are "final" which means it won't be possible to subclass.
>> However, I am disappointed with this restriction because I would like to
>> use inheritance as an easy way of composing value types. Brian, what are
>> your thoughts about this?
>
> Nothing is free.
>
> Here's one example of where the flexibility you want (and I understand 
> why you want it, restrictions usually feel restrictive) interferes 
> with the performance you want.  Suppose I could do this:
>
> value class A {
>    int x;
>    int y;
> }
>
> value class B extends A {
>    int z;
> }
>
> A[] array;
>
> OK, how do I lay this out now?  Part of the point was that I want a 
> packed layout without object headers.  But if I don't know how big a B 
> is, I can't have this.  (I don't even know whether there are other 
> subclasses of A out there that haven't even been loaded yet, and might 
> be even bigger than B.  So I can't do the simplistic thing of "take 
> the biggest subclass layout I've seen at time of array instantiation".)
>
>

What if A and B as value types were unrelated? Just their boxed 
counterparts would be related.

Peter