Value Types in Object-Oriented Programming Languages

[B. Ritterbach]

Hi Brian,

 >But such a strict interpretation would be of too limited use for Java
I admit, not being bound to restrictions of an existing language made 
things a bit easier when we were working on the subject.

 >  imagine value types that cannot represent even something as simple 
as a tuple of (String, String).
acually, within our language model, a tuple of (String, String) would be 
a value type.
Also a String type would be a value type within this setting, because of 
its logical properties (immutable, no creation, operation that are 
referentially transparent and free of side effect.)
As Simon has pointed out, there are many commonalities between value 
types in Valhalla and value types in the thesis.
Probably the only difference:  in our model, value types need not 
necessarily be supported "by value" when they are implemented. Very 
often this is possible, which makes the implementation fast and 
efficient, a great collateral benefit. But even if support "by value" is 
not possible (e. g. for strings or for infinite precision integers) they 
remain values and are used in a value-like way.

Cheers,
Beate

On 17.07.2015 22:50, Brian Goetz wrote:
>> the thesis looks pretty interesting!
> Indeed, I look forward to stumbling through it with my limited mastery of German.  (But not this week, I’m on vacation.)
>
>> Value types in your model have bigger restrictions, like referential
>> transparency, no reference types inside value types (which makes them
>> practically pointer-free), no passing or accessing references in value type
>> methods, ... which feels like a larger split introduced into the language, with
>> a mutable, reference-passing model on the one side and an immutable
>> value-passing model on the other side.
> This purity-vs-practicaly crossroads is one that we spent some time staring at as well.  Languages like LiMe (designed for GPU computation) take a pure values-all-the-way-down approach, which is appropriate given the target they are aiming at.  But such a strict interpretation would be of too limited use for Java — imagine value types that cannot represent even something as simple as a tuple of (String, String).  This compromise does undermine their value-ness, in part, since references are only values relative to the heap they were born with — and this becomes a visible seam when you serialize + deserialize a value containing a reference.  But, it is a compromise we need to live with, just as the primitive-vs-ref divide is a compromise we live with — because the alternative is impractical.
>
> Cheers,
> -Brian
>
>
>