Value types questions & comments
forax at univ-mlv.fr
Mon Apr 18 17:33:55 UTC 2016
----- 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é: Vendredi 15 Avril 2016 00:18:51
> Objet: Re: Value types questions & comments
> On Tue, Apr 12, 2016 at 1:51 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> One terminology we’ve been experimenting with is having “class” and
> > “species” (think back to middle school: kingdom, phylum, class, order,
> > family, genus, species.) List is a class; List<int> and List<erased> are
> > species of List. Similarly, the boxed projection and the value projection
> > of Complex are both species of class Complex.
> > Not clear whether this is the right terminology, but it gives users a way
> > to to keep thinking that List is a class, while recognizing that the beasts
> > List<int> and List<erased> are at the same time both of class List and also
> > of different species.
> Just saying: the need to introduce "species" is an example of how this
> proposal makes Java fundamentally more complex and confusing, in a way that
> will affect everyone.
I try to understand your point,
you mean that even if specialization implies reification of generics (for primitive and value-types) for the runtime,
you don't want that 'detail' to surface in the language/API, i.e. have no way to ask at runtime for the species of an instance.
That's an interesting idea.
BTW, i find 'species' to be an horrible name because it's always sound like a plural in English, no ?
> So, how about:
> > - Java has always had values
> > - Primitives are the BUILT-IN values
> > - Java now gets USER-DEFINED values in addition to USER-DEFINED classes
> > - USER-DEFINED values and classes can have fields, methods, constructors,
> > and implement interfaces
> > Does this stacking make it sound less radical?
> I still think this loses compared to simply admitting that there are now
> three kinds of types. I can tell that we *want* that to not be true, but we
> will not achieve that.
I agree with Kevin about the 3 kinds of types.
At least until, there is a way to make primitive behave like value type (have methods, implements interface, etc.).
> Using a value type for something that *isn't a value* raises alarm bells
> > for me. At the minimum I would expect this user to have to implement eq/hc
> > by hand, because the default behavior users want 99% of the time is (deep)
> > content-based equality.
> > This may be the reality-distortion field speaking, but in my view a
> > reference *is* a kind of value — albeit a very special kind. They’re
> > immutable, like other values. Almost all their state is encapsulated (they
> > can be compared by identity, that’s it). They can only be constructed by
> > privileged factories (we call these constructors.) But, ultimately, they
> > behave like values — they are passed by value, they have no identity of
> > their own.
> Well, FYI, this confuses and worries me.
> For the Cursor class, the natural definition of equals *is* the
> > componentwise one — two cursors are the same if they refer into the same
> > source at the same position. But yes, there are cases where we’d want to
> > hand-override equals (which is allowed) to do a deeper comparison
> > (generally when our components are value-like references, like strings or
> > dates or big decimals.)
> And again, I think this orientation is very wrong. Deep content-based
> equality is what most users will expect, and will want most of the time. If
> we don't do that, I think we may be fairly accused of thinking too much
> about the kind of code *people like us* write, not the kind of code that
> most Java users write.
> This actually gets back to a much broader point. This whole project is
> motivated by performance. However, it would be very sad if it does not
> solve a second problem at the same time, because it can. Even Java
> developers who are content with the performance foibles of their existing
> "value-based classes" are constantly irritated by the burden and bug-prone
> nature of writing/maintaining such classes. At Google we have resigned
> to *code-generating* these things, which we are currently doing 16,500
> times and climbing. Few of this resemble your stated use cases (cursors,
> tuples, numerics, etc.). They are just the everyday data that our
> applications pass around. imho, it really should be an explicit goal of
> this project to make hacks like that obsolete. A lot of people would cheer
> that feature even if these still compiled to regular old classes!
The main issue i see with deep-equals is that you may have cycle because a value type can embody a reference to itself.
So for me it's a separate feature. Maybe this feature can be introduced at the same time as value type.
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
More information about the valhalla-spec-observers