On Apr 10, 2019, at 5:11 AM, Doug Lea <[email protected]> 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
