Value types - compatibility with existing “value objects”

[Brian Goetz]

> 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".)