Two points from me for the record:

1. I re-read the JEP draft now titled Value Objects, and liked everything I 
saw, including the new/old term “Value” replacing “Pure” and “Inline”.

2. In your mail, and in the companion JEP draft titled Primitive Objects, you 
refer to “primitive classes” and their objects.  It would make our 
deliberations simpler, IMO, if we were to title this less prescriptively as 
“Primitives” or “Primitive Types” or “Primitive Types and Values”, rather than 
“Primitive Classes”, because (a) there’s no logical need for the new things to 
be classes, and (b) it might actually be helpful for them *not* to be, in the 
end, after deliberation.  Putting the word “classes” in the title presupposes 
an answer to deliberations that have not yet been concluded.

People should note that the term “class” and “object” is only loosely bound to 
the term “primitive” in most of our designs, since (of course) today no 
primitives at all are either defined by classes or have objects.  They have 
corresponding reference or box classes and objects, to be precise.  Today a 
primitive type “has a class” but it is not the case that it “is a class”.  We 
could choose to preserve this state of affairs instead of fixing it by making 
“classes everywhere”; it makes some dependent choices easier to make.  As you 
know, one possible bridge to the future is, “Today all types are a disjoint 
union of primitives, classes, and interfaces, and tomorrow the same will be 
true, with all three possessing class-like declarations.”

What about objects, shouldn’t primitives at least be objects?  Well, interfaces 
don’t directly have objects today; they have objects of implementing classes.  
Likewise, primitives need never have objects directly, as long as they have 
objects which properly relate to them—their boxes.  Boxes-boxes-everywhere 
certainly has its downsides, include pedagogical downsides, but that doesn’t 
make it a non-starter.

Instead, if we choose to use the terms “primitive class” and “primitive object” 
as exact counterparts to “reference class” and “reference object”, as your 
chart suggests, Dan, we will have to account for the duplication and/or ad hoc 
division of various attributions of classes and objects between the “primitive  
class” and its corresponding “reference class” (e.g., int.ref, Point.ref).  I 
think a good leading question is, “if a primitive is a class, and its reference 
type is also a class, which of its methods are situated on the primitive class, 
and which are situated on the reference class?”  I would suggest that we be 
more sure we want to have two classes per primitive, or only-a-primitive-class 
per primitive, before we presuppose a decision by putting the word “Classes” in 
the title of JEP 402.

> On Nov 29, 2021, at 4:09 PM, Dan Smith <daniel.sm...@oracle.com> wrote:
> 
> I've been exploring possible terminology for "Bucket 2" classes, the ones 
> that lack identity but require reference type semantics.
> 
> Proposal: *value classes*, instances of which are *value objects*
> 
> The term "value" is meant to suggest an entity that doesn't rely on mutation, 
> uniqueness of instances, or other features that come with identity. A value 
> object with certain field values is the same (per ==), now and always, as 
> every "other" value object with those field values.
> 
> (A value object is *not* necessarily immutable all the way down, because its 
> fields can refer to identity objects. If programmers want clean immutable 
> semantics, they shouldn't write code (like 'equals') that depends on these 
> identity objects' mutable state. But I think the "value" term is still 
> reasonable.)
> 
> This feels like it may be an intuitive way to talk about identity without 
> resorting to something verbose and negative like "non-identity".
> 
> If you've been following along all this time, there's potential for 
> confusion: a "value class" has little to do with a "primitive value type", as 
> we've used the term in JEP 401. We're thinking the latter can just become 
> "primitive type", leading to the following two-axis interpretation of the 
> Valhalla features:
> 
> ---------------------------------------------------------------------------------------------
> Value class reference type (B2 & B3.ref)      | Identity class type (B1)
> ---------------------------------------------------------------------------------------------
> Value class primitive type (B3)                       |
> ---------------------------------------------------------------------------------------------
> 
> Columns: value class vs. identity class. Rows: reference type vs. primitive 
> type. (Avoid "value type", which may not mean what you think it means.)
> 
> Fortunately, the renaming exercise is just a problem for those of us who have 
> been closely involved in the project. Everybody else will approach this grid 
> with fresh eyes.
> 
> (Another old term that I am still finding useful, perhaps in a slightly 
> different way: "inline", describing any JVM implementation strategy that 
> encodes value objects directly as a sequence of field values.)
> 
> Here's a new JEP draft that incorporates this terminology and sets us up to 
> deliver Bucket 2 classes, potentially as a separate feature from Bucket 3:
> 
> https://bugs.openjdk.java.net/browse/JDK-8277163
> 
> Much of JEP 401 ends up here; a revised JEP 401 would just talk about 
> primitive classes and types as a special kind of of value class.
> 

Reply via email to