Fwd: IdentityObject/InlineObject naming

[Brian Goetz]

Received on the -comments list.

If I understand it correctly, your claim is that a "plain" object is 
immutable/non-lockable but supports polymorphism (you need identity for 
mutability, otherwise you don't know what object you are mutating.)  
`==` on plain objects would have to be state-based as with inlines today 
(there's no identity to compare.)  Inline objects "subtract" from that 
by ruling out polymorphism; Identity objects would "add" to that to 
support mutability, reference-based equality, and synchronization.

Essentially, this is a "split" over "lump" move; there are true values 
(inlines), polymorphic values, and identity objects. It's not crazy, and 
as you say there was a possible ordering of events that would more 
naturally build that tower, but that's not the world we have.

(Actually, if we're splitting, we could split more than three ways; 
plenty of people would prefer something that is inlinable but mutable -- 
where mutation would be "promoted" to the innermost enclosing container 
with identity.  You might call these "structs", which would be mutable 
but identity-free (they borrow an identity for mutation purposes.))

Would Java developers be well-served by splitting the world into three, 
rather than two, where identity is selected separately from 
polymorphism?  I don't see it.


FTR, the current thinking is that we need `IdentityObject` (because you 
want to be able to use it as an API type / bound) but don't really need 
`InlineObject`, which is more "inline" with what you are saying at the 
end: `class Foo implements IdentityObject` has a more additive feel.


-------- Forwarded Message --------
Subject: 	IdentityObject/InlineObject naming
Date: 	Wed, 20 May 2020 00:44:21 +0100
From: 	Stephen Colebourne <scolebourne at joda.org>
To: 	valhalla-spec-comments at openjdk.java.net



Some comments wrt IdentityObject/InlineObject naming.

The current valhalla state is that "Inline classes have some
restrictions compared to ordinary (identity) classes; they are final,
their fields are final, and their ability to participate in
inheritance is limited." But these restrictions imply to me that there
are three concepts a developer might want to express in the future:

- an "identity" object (needs identity/synchronization for compatibility)
- a "plain" object (no need for identity/synchronization)
- an "inline" object (needs to be inline for performance and can
accept the restrictions)

While it is understandable that there is a reluctance to open the can
of worms for "plain" objects, they are clearly a basic concept. ie.
once you discuss the presence of identity, you naturally discuss the
absence of it. Yet the concepts around inline are in many ways
orthogonal. (Imagining a world where "plain" objects were added to
Java, then 10 years afterwards "plain" objects would be the norm, and
"identity" objects would be very rare). I mention the above, because
it bears on the naming choices available. Even if you don't want to
tackle plain objects now, the naming choice could make it harder to
add them later.

I also struggle with a single interface extends/implements hierarchy
because developers can write "extends Object" today:

- "class Foo" (default) => identity
- "class Foo extends Object" => identity
- "class Foo extends Object implements ObjectIdentity" => identity
- "class Foo extends Object implements ObjectInline" => identity and 
inline ???

With a single new interface, the hierarchy is implying that
"implements ObjectInline" *subtracts* identity, something that object
hierarchies do not do.

Keeping an ObjectInline interface appears better placed to tackle this
particular pedagogical problem, as it seems more explainable that:
- a class always extends Object
- a class always implements either ObjectIdentity or ObjectInline
- the defaults are "extends Object" and "implements ObjectIdentity"
ie. this makes more sense because manually writing "extends Object"
only impacts bullet point 1, not bullet points 2 and 3

Some other possible names:
- ObjectIdentifiable / ObjectInlineable
- JvmIdentifiable / JvmInlineable

Stephen