Value Types in Object-Oriented Programming Languages

[Beate Ritterbach]

Hi, John,

thanks for your answer.
Here some thoughts about your objections:

 > If this reasoning were applied to the JVM, it would seem that 
PairValue<T,U> or OptionalValue<T> could not be instantiated with 
reference types T or U.

The issue of types like PairValue<T,U> or OptionalValue<T> is indeed a 
tricky one, because it involves generics.
When using a type like PairValue<T,U> , T and U can be be instantiated 
both with an object type or a value type.
In the definition of type PairValue<T,U> you cannot access any methods 
of T and U  (except identity/ equality), so the value-like behavior of 
PairValue<T,U> cannot be destroyed. Thus from a conceptual point of view 
everything looks fine.
I admit, that this set-up - T sometimes instantiated with an object type 
(technically: a reference), some other times with a value type 
(technically: potentially a bit pattern representing the value itself) 
may be hard to implement.


 > Maybe in your framework, for cases like that, you need to distinguish 
an object per se from a reference to the object, and treat T and U as 
references which require "conversion" to objects via a cast.

Within our framework, there is not distinction between an instance and a 
reference to the instance at all (be the instance a value or an object). 
To be more precise: no distinction visible to the application programmer.
In the underlying implementation, the language environment needs to 
decide whether a value is implemented directly or via reference, and the 
decision has to consider the value types definition, especially the size 
of its representation. Values with "big" representations, or values with 
unknown representation size - such as strings or infinite precision 
integers - will need to get implemented with references. Values with 
"small" representations - like points, dates, complex numbers, rational 
numbers, monetary amounts - may be implemented directly.

Cheers, Beate