Value types questions & comments

[Kevin Bourrillion]

Still thinking

On Mon, Apr 11, 2016 at 4:13 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

For example, I see no reason why `int` can’t implement Comparable or
> Serializable ...
>
> We might even take this further — by actually describing `int` with a
> source file (public native class int implements Comparable { … }) which
> might try and smooth out some of the differences, but I wouldn’t hold out a
> lot of hope for this being super successful.
>

I now think that neither of these bits will accomplish much. Implemented
types only mean anything to the *boxed* form, but int doesn't even use
"that" kind of boxing; it must continue to be boxed to java.lang.Integer as
always, and nor is there a way to make Integer <handwave> "extend
Box<int>", which would have bought us a few things, because it has to
extend Number (which tragically is not an interface).

So, I think you're looking at a taxonomy something like this:

Types
  +-- Reference types
  +-- Value types
          +-- Primitives / "builtin value types"
          +-- "Custom value types"

... and basically we need to diligently use the term "custom value types"
instead of "value types" whenever talking about information that doesn't
apply to primitives.

But, I think that this will also not work out well, because it belies the
many commonalities between kinds 1 and 3 that primitives don't share (they
have a source file, they get loaded and initialized, they have methods....).

I'm back once again to the idea that there are just plain *three different
kinds of types*, where value types are largely but not entirely a hybrid of
the other two. Now, sure, the more *areas* (such as specialization) in
which we can make primitives and value types work identically the better.


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com