State of the Values

Paul Benedict pbenedict at apache.org
Tue May 6 21:29:22 UTC 2014


I may have answered my own questions after a second reading of the spec. If
anyone thinks these answers need tweaking, please let me know.

1) To keep foreign pointers out of value types, and therefore make sure
they are "safe", means to only allow construction parameters that are (1)
one of the 8 natives or (2) another value type. The latter essentially is a
form of "subclassing" but only by copying the values into the new value and
adding more data points.

2) Spec says the "value" type will not extend java.lang.Object but the
boxed type will.

Now some musings...
The proposal allows value types through a special keyword (perhaps) and
special construction (perhaps). I am not fond of this at all and makes me
think of the C schism of struct vs. classes and their separate coding
styles. Rather, I propose we look at value types as Java classes that
implement a special "no identity" interface contract and let the JVM
transform them natively into true value types. In other words, the
programmer should write the boxed version, which meets whatever restricted
guidelines set forth, and then the JVM can perform its optimizations
invisibly. I think Brian Goetz was going down the right path with his
(emulated) "value based class" contract in his lambda support. I'd like to
see that path continue using today's language constructs rather than dual
syntax/coding styles.

Paul



Cheers,
Paul


On Sun, May 4, 2014 at 12:27 PM, Paul Benedict <pbenedict at apache.org> wrote:

> These two questions came to mind:
> 1) If subclassing will be prohibited, will it still be possible to
> "extend" another value type via delegation? I imagine people will want to
> delegate to reuse existing value classes.
>
> 2) The draft makes mention how most java.lang.Object methods aren't
> applicable. So does it make sense for value types to extend
> java.lang.Object? Or, will it take the "enum" route (all extending
> java.lang.Enum) of forcibly subclassing a new java.lang type and providing
> "final" behavior for the non-applicable methods?
>
> Cheers,
> Paul
>


More information about the coin-dev mailing list