Value types questions & comments

[Remi Forax]

Hi Kevin,

----- Mail original -----
> De: "Kevin Bourrillion" <kevinb at google.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: valhalla-spec-experts at openjdk.java.net
> Envoyé: Mardi 3 Mai 2016 01:34:42
> Objet: Re: Value types questions & comments
> 
> Still thinking

so am i ...

> 
> 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.
> 

yes, from the specialization point of view you want to be able call methods equals/hashCode/toString on a type variable bound by any,
or bound that type variable by an interface like Comparable.

public class Tree<any T extends Comparable<T>> {
  ...
} 

given that we want,
  Tree<int> tree = ...
to be legal, it seems weird to not conclude that int implements Comparable<int>.
if int implements an interface, then calling a method on a variable of type int seems not that weird too.

So IMO, the distinction between builtin primitive / custom value type seems arbitrary if a primitive type can implement an interface and a method can be called on it. 


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

Rémi