Value Types in Object-Oriented Programming Languages
brian.goetz at oracle.com
Fri Jul 17 20:50:33 UTC 2015
> 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