generic specialization design discussion

[John Rose]

On Apr 10, 2019, at 5:11 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> But maybe Brian is right and "inline" is good enough.

I think it's good enough, and I'm glad to get beyond
"value".

There's another shoe that needs to drop here, another
term which is *not* good enough, for us to bikeshed:
"reference".  If we could get away with saying "value"
and "reference" have a special meaning as adjectives,
we could allow those terms, as nouns, to retain their
standard meanings in the JVMS.

Here's the background:  The JVMS takes great care to
use the terms "reference" and "value" with
precision, and this occasionally surfaces in explanations
meant for ordinary Java users.  We have already released
the term "value" from its new duties; I think we have an
equal need to release "reference" from its new duties
as well.

(Put another way:  The JVMS says that all a-series opcodes
take "reference" arguments, and all L-series descriptors
denotes reference variables.  In L-world "reference" means
a value which refers potentially to either an inline object
or a non-inlinable identity-laden object.  Changing this
term is IMO not feasible.  I'm arguing against overloading
as well.)

So what we need is a formal term NI which means "not
inline", the opposite of the formal term "inline".

(I pause for the Knights of Ni to ride by.)

NI should not be spelled "reference" because that term
is already committed elsewhere, and in particular we
will have to say that inline objects are manipulated
by references in the JVM.

We don't need a *keyword* for NI.  If pressed for such
a thing, we could invent "non-inline" as a composite
keyword.  But the ValObject/RefObject classes provide
a fine way to document programmer intent:  If I want
to prevent maintainers from sticking "inline" in front
of my class, I can derive from RefObject explicitly.

(Note that both Val and Ref are past their shelf life.
More in a moment.)

We *do* need a positive term for documentation.
We want to say things like, "if the object is inline,
do this, else the object is NI, so do that".  And if
we are talking about legacy object operations
like Object::wait, it would be best if NI could
express more than just the negation of inline,
but had its own proper connotations that suggest
the identity of a non-inline object.  That's what
I mean by a positive term.

So, for example, NI could be some term which
conveys the idea of being "identity-laden".  Or
it could convey synchronizable, or having a
unique address/location/heap-block.

Finally, we need to use the positive term inline
and the positive term NI to construct the very
useful type names formerly known as ValObject
and RefObject.  Clearly, those names should be
readable in code as "inline object" and "NI object".

Now for a NI bikeshed color.  I think it is sufficient
to use the term "identity" for NI.

Thus, we would have:

 - inline classes and identity classes
 - inline types and identity types
 - the top types InlineObject and IdentityObject
 - inline objects and identity objects
 - inline values and identity values
 - inline references and identity references
 - informally, maybe "inlines" and "identities"

(Or maybe something like InlineObj and IdentityObj
or InObject and IdObject, if we feel the need to
abbreviate.)

What other colors are there for NI?

— John