Value Types in Object-Oriented Programming Languages
ritterbach at web.de
Sat Jul 18 10:01:01 UTC 2015
>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.
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.
More information about the valhalla-dev