Aggressive unboxing of values: status update

[John Rose]

On Nov 11, 2014, at 4:37 AM, Victor Nazarov <asviraspossible at gmail.com> wrote:

> But I'd like to state some of my
> ideas as I haven't heard something like this considered for implementation
> of value types.

The theme of both of your suggestions is to make deeper use of interfaces to distinguish and control the object-like and number-like features of values.  Please read http://cr.openjdk.java.net/~jrose/values/values-0.html for a sample of our discussions.

The details of your suggestions tend towards "splitting" independent features into separate interfaces.  This is degree of freedom in API design which can be moved along a spectrum from "everything in Object" to "every method in its own interface".  (See also http://en.wikipedia.org/wiki/Lumpers_and_splitters .)

We are definitely discussing using interfaces with values in these ways.  The values document explicitly contemplates such uses.  (We would be crazy not to!)  See two excerpts below; the second one proposes a "lumpier" interface than yours, which is purely provisional.

The Haskell and Scala communities have invested enormous efforts exploring these areas, often with a splitting tendency in their API designs.  One big challenge for designing Java value APIs is to adopt the best insights from such projects, but adapt them to the common style of Java APIs.  Those APIs tend towards lumping, in order to reduce type count and provide a simpler initial experience.

— John

> Besides `Object`, other types such as `Comparable` should
> also be able to interoperate with suitable value types,
> opening the door to types like `TreeSet<UnsignedInteger>`.
> (This implies that interfaces may sometimes claim subtypes
> which are not also subtypes of `Object`.)

> We expect every value to implement an ad hoc interface or abstract
> super type that looks something like this:
> 
>     interface __Objectable<ThisType> {
>       default String toString() {...}
>       default int hashCode() {...}
>       default boolean equals(ThisType) {...}
>     }