Re: generic specialization design discussion

[John Rose]

On May 8, 2019, at 12:31 PM, Dan Smith  wrote:
> 
> I'm working on the introductory spec material, and have also come to this 
> conclusion. All values are either *primitives* or *references*. Everything 
> we've done in L-world has to do with refining the space of things that 
> references can point to (*objects*).
> 
>> ...
> 
> Here's a cut of JVMS 2.4 that incorporates some of this terminology (some of 
> it I've avoided, either because I didn't need it, or it seemed insufficiently 
> precise.)
> 
> I also decided to call out the `Object` type as a unique entity. This 
> probably have some ripple effects elsewhere, which I haven't explored yet.
> 
> It's hard to say much about identity without talking about 
> acmp/substitutability; I chose the term "identical" here for that purpose 
> (rather than the overloaded "equal").

When the current JLS and JVMS must talk about object identity
(identicality??) they tend to use the term "same".  It's such a
humble word it's easy to miss.  Maybe the latinate term
"identical" is better, although it's confusingly similar to "identity".

What you've written reads very well, and I have no suggestion
for improving it, except that the stuff about "nullable" and
"null-free" will shortly be false, when we introduce inline
classes that encode null natively (as a combination of their
field values).

I did a careful search in the JVMS and JLS for the word "same"
and found these uses where "identical" could be a candidate
for replacing or clarifying "same":

> JVMS 5.4.3 Resolution
> Subsequent attempts to resolve the symbolic reference always succeed
> trivially and result in the same entity produced by the initial resolution.
> [condy may resolve to an inline instance]

> JLS 4.3.1 Objects
> There may be many references to the same object.
> Most objects have state, stored in the fields of objects that are instances of
> classes or in the variables that are the components of an array object.
> If two variables contain references to the same object, the state of the 
> object
> can be modified using one variable's reference to the object, and then the
> altered state can be observed through the reference in the other variable.
> …
> Example 4.3.1-2. Primitive and Reference Identity
> …
> Each object is associated with a monitor ([17.1]), which is used by
> `synchronized` methods ([8.4.3]) and the `synchronized` statement ([14.19]) to
> provide control over concurrent access to state by multiple threads ([17]).

> JLS 4.12.4 `final` Variables
> Once a `final` variable has been assigned, it always contains the same value.
> If a `final` variable holds a reference to an object, then the state of the
> object may be changed by operations on the object, but the variable will 
> always
> refer to the same object.
> This applies also to arrays, because arrays are objects; if a `final` variable
> holds a reference to an array, then the components of the array may be changed
> by operations on the array, but the variable will always refer to the same
> array.
> 
> JLS Example 8.3.1.1-1. `static` Fields
> These two ways of accessing the `origin` class variable access the same 
> object,
> evidenced by the fact that the value of the reference equality expression
> ([15.21.3])

> JLS Example 8.8.7.1-2. Qualified Superclass Constructor Invocation

> Perhaps surprisingly, the same instance of `Outer` may serve as the 
> immediately
> enclosing instance of `ChildOfInner` with respect to `Inner` *for multiple
> instances of `ChildOfInner`*. [careful outers could be inline objects]

> JLS Example 10.7-2. Shared Subarrays After A Clone
> showing that the `int[]` array that is `ia[0]` and the `int[]` array that is
> `ja[0]` are the same array.  [seems OK here]

> JLS 14.11 The `switch` Statement {#jls-14.11}
> -   No two of the `case` constants associated with the `switch` statement have
> the same value.  [can be java.lang.String references!]


> JLS 14.19 The `synchronized` Statement

> Acquiring the lock associated with an object does not in itself prevent other
> threads from accessing fields of the object or invoking un-`synchronized`
> methods on the object.  [may need to be restricted to identity objects]

> JLS Example 15.8.3-1. The `this` Expression
> If the other vector is the same vector object as the one for which the 
> `equals`
> method was invoked, then the check can skip the length and value comparisons.
> [seems OK here]
> JLS 15.21.3 Reference Equality Operators `==` and `!=`
> At run time, the result of `==` is `true` if the operand values are both 
> `null`
> or both refer to the same object or array; otherwise, the result is `false`.
> …
> The result of `!=` is `false` if the operand values are both `null` or both
> refer to the same object or array; otherwise, the result is `true`.

Also watch out for the phrase "same monitor".  It's safe if used
carefully, but it tends to go along with the assumption that objects
and monitors are in one-to-one correspondence, which 

Re: generic specialization design discussion

[Dan Smith]

> On Apr 18, 2019, at 4:08 PM, John Rose  wrote:
> 
> 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'm working on the introductory spec material, and have also come to this 
conclusion. All values are either *primitives* or *references*. Everything 
we've done in L-world has to do with refining the space of things that 
references can point to (*objects*).

> 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"

Here's a cut of JVMS 2.4 that incorporates some of this terminology (some of it 
I've avoided, either because I didn't need it, or it seemed insufficiently 
precise.)

I also decided to call out the `Object` type as a unique entity. This probably 
have some ripple effects elsewhere, which I haven't explored yet.

It's hard to say much about identity without talking about 
acmp/substitutability; I chose the term "identical" here for that purpose 
(rather than the overloaded "equal").

~~
### 2.4 Reference Types and Values

There are five kinds of reference types: identity class types, inline class 
types, array types, interface types, and the `Object` type.  Their values are 
references to *objects* or the special `null` reference.

An identity class type names a non-inline, non-interface class other than 
`Object` defined in a `class` file. The objects referenced by values of an 
identity class type are instances of the class or one of its subclasses. Each 
instance is dynamically allocated and has a unique *identity*, which is used to 
determine whether two references are identical. The instance encapsulates 
*fields*; the values of fields may be changed, but doing so does not change the 
identity of the object.

An inline class type names an inline class defined in a `class` file. The 
objects referenced by values of an inline class type are instances of the 
class. Each instance encapsulates fields whose values cannot be changed. Inline 
class instances do not have a unique identity—two references are identical if 
they reference instances of the same inline class and the values of the 
objects' fields are identical.

For each inline class, there is a *nullable* and a *null-free* inline class 
type. These types share the same set of values, with the exception that `null` 
is a value of the nullable type, but not the null-free type.

An array type names a *component type*, which may be `boolean`, any numeric 
type, or any reference type. The objects referenced by values of an array type 
are dynamically-allocated arrays. Each array object has a unique identity, a 
component type, and a vector of mutable components. The identity is used to 
determine whether two references are identical. The components store values of 
the component type; the number of components is fixed at allocation time, but 
is not constrained by the array type. Array types are covariant: if an array 
type has component type *T*, an array referenced by a value of the array type 
has a component type that is a subtype of *T*.

The component type of an array type may itself be an array type; such a type is 
a *multi-dimensional* array type. The *element type* of a single-dimensional 
array type is its component type; the element type of a multi-dimensional array 
type is the element type of its component type.

An interface type names an interface defined in a `class` file. The objects 
referenced by values of an interface type are instances of a class that 
implements the interface. These instances may be identity objects or inline 
objects. The objects referenced by values of interface types `Cloneable` and 
`java.io .Serializable` may also be arrays.

The `Object` type names the `Object` class. References of type `Object` may 
refer to any object: identity class instances, inline class instances, or 
arrays. Instances of the `Object` class itself are treated as identi

Re: generic specialization design discussion

[Doug Lea]

On 4/18/19 6:08 PM, John Rose wrote:
> ...
> 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.
> 
> 
> 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.

Not having any better ideas after sitting on this a while, I agree.
Some usages are about referring to an identity, not the identity itself.
But I don't know any everyday terms for this that work ("allusion" is
sorta close but weird).

-Doug

> 
> 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?
> 

Re: generic specialization design discussion

[John Rose]

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

Re: generic specialization design discussion

[Doug Lea]

On 4/9/19 6:03 PM, John Rose wrote:

> 
> Another one:  "immediate" instead of "inline".

Plausible. Following your thoughts in another post, the main property
that ought to clear to users is:

  Instances of X classes do not have independent identity.

If the audience were GOF Design Patterns readers, X would be "flyweight"
(https://en.wikipedia.org/wiki/Flyweight_pattern).

If the audience were those familiar with run-time mechanics, X might be
"interior" (such an instance is always at an offset of something else.)

But maybe Brian is right and "inline" is good enough.

-Doug

Re: generic specialization design discussion

[John Rose]

On Apr 9, 2019, at 2:06 PM, John Rose  wrote:
> 
> Not bad.  More riffing:

Another one:  "immediate" instead of "inline".
Connotation from assembly code is "stuck in the
middle of something else, not a variable".
Etymology is "nothing between the user and
the object, no mediator".  Regular objects
have *object identity* as the mediating factor
between the object and every user.

https://www.thesaurus.com/browse/immediate and
https://www.thesaurus.com/browse/near-at-hand
also have "direct", "adjacent", "close", "near",
"contiguous", "available", and many more.

Vladimir I. suggests that an ideal keyword will
suggest or imply immutability.  "Immediate" does
this, as well as suggesting that the thing is available
(inline) close at hand.

Re: generic specialization design discussion

[John Rose]

On Apr 9, 2019, at 1:41 PM, Daniel Heidinga  wrote:
> 
> Riffing on the "inline" term and tying things back to the flattenable 
> discussions - what about using "flat" as the keyword?
>  

Not bad.  More riffing:

https://www.thesaurus.com/browse/flat
also has "spread out" and "level".

Etymologically, a single-layer structure is "simplex",
as opposed to a folded "complex" structure.  What's
a class without identity? A "mere", "simple" class.

https://www.thesaurus.com/browse/simple
has a bunch of synonyms.

https://www.thesaurus.com/browse/plain
has "open" and "lucid" and "transparent".

https://www.thesaurus.com/browse/featherweight
has "lightweight", "agile", "nimble", "loose", "sheer"

Regarding the ability to make the same object
in many places, "uncopyrighted".
https://www.thesaurus.com/browse/reproduce
suggests "repeatable", "replicant".

value class Foo { }
inline class Foo { }
flat class Foo { }
simple class Foo { }
simplex class Foo { }
spread class Foo { }
mere class Foo { }
lightweight class Foo { }
transparent class Foo { }
nimble class Foo { }
replicated class Foo { }

Re: generic specialization design discussion

[Daniel Heidinga]

Riffing on the "inline" term and tying things back to the flattenable discussions - what about using "flat" as the keyword?
 
flat class Foo { }
 
flat record R (int i);
 
--Dan
- Original message -From: Maurizio Cimadamore Sent by: "valhalla-spec-experts" To: Brian Goetz , Doug Lea Cc: valhalla-spec-experts Subject: Re: generic specialization design discussionDate: Tue, Apr 9, 2019 4:10 PM 
On 09/04/2019 18:04, Brian Goetz wrote:> In addition to liking the sound of it, I like that it is more “modifer-y” than “value”, meaning that it could conceivably be applied to other entities:>>      inline record R(int a);>>      inline enum Foo { A, B };>I like it too - especially because in C/C++ "inline" doesn't actually_force_ the compiler to do anything. So, I like the hint-y nature ofthis keyword and I think it brings front & center what this feature isabout in a way that 'value' never really did (users asking about thedifference between records and values is, I think, a proof of thatparticular failure).Maurizio 
 

Re: generic specialization design discussion

[Maurizio Cimadamore]

On 09/04/2019 18:04, Brian Goetz wrote:

In addition to liking the sound of it, I like that it is more “modifer-y” than 
“value”, meaning that it could conceivably be applied to other entities:

 inline record R(int a);

 inline enum Foo { A, B };

I like it too - especially because in C/C++ "inline" doesn't actually 
_force_ the compiler to do anything. So, I like the hint-y nature of 
this keyword and I think it brings front & center what this feature is 
about in a way that 'value' never really did (users asking about the 
difference between records and values is, I think, a proof of that 
particular failure).


Maurizio

Re: generic specialization design discussion

[John Rose]

On Apr 9, 2019, at 11:55 AM, John Rose  wrote:
> 
> It's not like the UML experts are looking at the last
> two decades of our thrashing out the value model,
> and saying "yep, we wondered when you would get
> here".  They are as stuck in the Smalltalk model as
> we were.

P.S. I did a quick scan for mentions of object identity
in this available document:
  https://www.omg.org/spec/UML/2.5.1/PDF

The term "identity" is assumed but not defined, which
IMO is a hallmark of Smalltalk-era object modeling,
the kind of model we are struggling to get at arm's
length so we can wrap our arms around it.

Here's a quote from page 151:

> The effect property may be used to specify what happens to objects passed in 
> or out of a Parameter. It does not apply to parameters typed by data types, 
> because these do not have identity with which to detect changes.

(Data types are like Java primitives or value types.)

Page 459, on identity tests:

> If an object is classified solely as an instance of one or more Classes, then 
> testing whether it is the “same object” as another object is based on the 
> identity of the object, independent of the current values for its 
> StructuralFeatures or any links in which it participates (see sub clause 
> 11.4.2).


Page 460 on class changes (e.g. CLOS change-class):

> The identity of the input object is preserved, no behaviors are executed, and 
> no default value expressions are evaluated. The newClassifiers replace 
> existing classifiers in an atomic step, so that structural feature values and 
> links are not lost during the reclassification when the oldClassifiers and 
> newClassifiers have structural features and associations in common.

If this paragraph were guarded by language saying
"the input object must be of the Foo kind", then we
could look for an anti-Foo in the spec.  But it's not.

One useful bit is the definition of "data type", on page
167.  And this is where the UML folks have the best
claim to asking us "what took you so long?".

> 10.2.3.1 DataTypes
> 
> A DataType is a kind of Classifier. DataType differs from Class in that 
> instances of a DataType are identified only by their value. All instances of 
> a DataType with the same value are considered to be equal instances.
> 
> If a DataType has attributes (i.e., Properties owned by it and in its 
> namespace) it is called a structured DataType. Instances of a structured 
> DataType contain attribute values matching its attributes. Instances of a 
> structured DataType are considered to be equal if and only if the structure 
> is the same and the values of the corresponding attributes are equal.
> 
> Unified Modeling Language 2.5.1 167
> 
> A DataType may be parameterized, bound, and used as TemplateParameters.

As a bonus, we also have:

> 10.2.3.2 Primitive Types
> 
> A PrimitiveType defines a predefined DataType, without any substructure. A 
> PrimitiveType may have algebra and operations defined outside of UML, for 
> example, mathematically. The run-time instances of a PrimitiveType are values 
> that correspond to mathematical elements defined outside of UML (for example, 
> the Integers).

So, if we want to follow UML, we could call value/inline classes
something like "data type" classes or "structured data" classes.
(Now I sympathize with C# structs.)

We might have to give up on saying that "classes have instances
which are objects" and similar things because UML makes a strong
distinction between identity-free data types and identity-laden
objects.  One of our basic principles in Valhalla is "codes like a
class".  UML says "classifier" instead of "class", and seems to
allow data types to have "classifiers", so that's OK.  We'd have to
give up our use of the term "object" or bend away from UML
usage there, because our inline classes define structure data,
not objects, in UML terms.

Basically, UML policy is to first distinguish by-value structured
data types from by-identity objects, but that's not our policy.
We build everything from objects.  Oddly, this doesn't contradict
UML as a modeling facility, but where UML allows identity-sensitive
operations on arbitrary objects, we have to say (a) such an operation
is partial, and applies only to some objects, or (b) such an operation
is interpreted (as == and hashcode) without reference to identity,
for objects which lack identity.

Maybe we could smuggle classifiers for NoIdentity and HasIdentity
into a future version of UML, with appropriate bounds for UML's
identity-sensitive operations?  Then it could describe the structure
we are building.

— John

Re: generic specialization design discussion

[Remi Forax]

- Mail original -
> De: "Brian Goetz" 
> À: "Doug Lea" 
> Cc: "valhalla-spec-experts" 
> Envoyé: Mardi 9 Avril 2019 19:04:36
> Objet: Re: generic specialization design discussion

> OK, let’s make this problem a little simpler.  The question of terminology in
> the JVMS is harder, but we have a syntax decision to make at the source code
> level.  So far its been proposed we replace “value class” with
> 
>inline class Foo { }
> 
> In addition to liking the sound of it, I like that it is more “modifer-y” than
> “value”, meaning that it could conceivably be applied to other entities:
> 
>inline record R(int a);
> 
>inline enum Foo { A, B };


It's very Kotlinish.

I like it more because it's not 'value' than for its name per se.
I have started to dislike 'value' because it has moved the cursor too much to 
the primitive side (Complex) and less to the abstraction side (Optional).

I think that choosing 'inline' is a step to the right direction.

The right direction obviously being the one where we all acknowledge that == 
being the substitutability test should be opt-in :)

Rémi

> 
> 
> 
>> On Apr 8, 2019, at 7:50 PM, Doug Lea  wrote:
>> 
>> On 4/8/19 6:44 PM, John Rose wrote:
>> 
>>> If we move terms around so "value" gets replaced by "inline",
>>> and "reference" by "indirect", only the first two lines are
>>> affected:
>>> 
>>> “inline object”, “indirect object” (also inline or indirect instance)
>>> “inline class”, “indirect class” (also inline or indirect type)
>>> 
>> 
>> It would be nice not to use new terms for old concepts (even if new to
>> Java). For alternative terminology originally stemming from similar
>> struggles to make such distinctions, see UML "Composition" vs
>> "aggregation" (also vs "association"). Wikipedia has some definitions:
>> https://en.wikipedia.org/wiki/Class_diagram#Aggregation
>> 
>> The UML specs say more but behind wall at https://www.omg.org/spec/UML
>> 
>> -Doug

Re: generic specialization design discussion

[Brian Goetz]

> I had sworn not to have opinions about syntax, because my reactions are
> probably not typical, but "inline" seems to under-stress issues users
> should keep in mind. How about "internal"?
> 
> internal class Foo(); internal record R();

I think most users think “internal” is associated with encapsulation, such as 
packages not exported by a module.

But, let’s step back: what issues that users should keep in mind need 
additional stressing?

Re: generic specialization design discussion

[Doug Lea]

On 4/9/19 1:04 PM, Brian Goetz wrote:
> OK, let’s make this problem a little simpler.  The question of terminology in 
> the JVMS is harder, but we have a syntax decision to make at the source code 
> level.  So far its been proposed we replace “value class” with 
> 
> inline class Foo { }
> 
> In addition to liking the sound of it, I like that it is more “modifer-y” 
> than “value”, meaning that it could conceivably be applied to other entities:
> 
> inline record R(int a);
> 
> inline enum Foo { A, B };

I had sworn not to have opinions about syntax, because my reactions are
probably not typical, but "inline" seems to under-stress issues users
should keep in mind. How about "internal"?

internal class Foo(); internal record R();

-Doug

Re: generic specialization design discussion

[John Rose]

On Apr 8, 2019, at 4:50 PM, Doug Lea  wrote:
> 
> On 4/8/19 6:44 PM, John Rose wrote:
> 
>> If we move terms around so "value" gets replaced by "inline",
>> and "reference" by "indirect", only the first two lines are
>> affected:
>> 
>> “inline object”, “indirect object” (also inline or indirect instance)
>> “inline class”, “indirect class” (also inline or indirect type)
>> 
> 
> It would be nice not to use new terms for old concepts (even if new to
> Java).

FTR, I agree and that's why I like "inline" and "indirect".

> For alternative terminology originally stemming from similar
> struggles to make such distinctions, see UML "Composition" vs
> "aggregation" (also vs "association"). Wikipedia has some definitions:
> https://en.wikipedia.org/wiki/Class_diagram#Aggregation

Quote from there: "Furthermore, there is hardly a difference
between aggregations and associations during implementation…"

That's the problem with UML:  It's too abstract.  It doesn't
give any guidance about implementation (nor should it).

But the JVM needs to set expectations about dynamics
as well as semantics, which means there's some hinting
about implementation.  Hence "inline" not "aggregation"
and "indirect" not "associated".  UML-native distinctions
like 1-1 vs. 1-N don't (AFAICS) help use describe this
lower-level distinction.

The deep reason for this is hidden in the JVMS word "same".
Only a single JVM heap block is the "same object" as itself,
if the object is a heap/indirect/regular object, which possesses
a unique identity tracked from def to use.  An inline object
can be the "same object" as another inline object even if
both occurrences of the "same object"  have independent
defs.

UML has a provision for describing state changes, but gives
less help in characterizing objects which have no state.
It seems to me that UML allows any object to have state,
potentially.  The abstraction might not let you observe the
state, but it might be there.  If UML were more explicit about
object equivalence (==) we could mine terms out of there.
I'm not enough of a UML expert to find if or where such
terms occur.

Googling takes me to https://www.uml-diagrams.org/object.html
where I find this definition of Object from UML 1.4.2:

> An entity with a well defined boundary and identity that
> encapsulates state and behavior. 


There's a more nuanced one in UML 2.5, but it's still not
useful AFAICS:

> An object is an individual [thing] with a state and relationships
> to other objects.


Looking at UML this little bit does suggest the modifier
"stateless" (entailing "don't use UML on me"?) as an
alternative to "value" and "inline".  I prefer a positive
term to a privative one, when possible, so "inline" is
better for me than "stateless" ("that which has no state").

It's not like the UML experts are looking at the last
two decades of our thrashing out the value model,
and saying "yep, we wondered when you would get
here".  They are as stuck in the Smalltalk model as
we were.

— John

> The UML specs say more but behind wall at https://www.omg.org/spec/UML
> 
> -Doug
> 

Re: generic specialization design discussion

[Brian Goetz]

OK, let’s make this problem a little simpler.  The question of terminology in 
the JVMS is harder, but we have a syntax decision to make at the source code 
level.  So far its been proposed we replace “value class” with 

inline class Foo { }

In addition to liking the sound of it, I like that it is more “modifer-y” than 
“value”, meaning that it could conceivably be applied to other entities:

inline record R(int a);

inline enum Foo { A, B };



> On Apr 8, 2019, at 7:50 PM, Doug Lea  wrote:
> 
> On 4/8/19 6:44 PM, John Rose wrote:
> 
>> If we move terms around so "value" gets replaced by "inline",
>> and "reference" by "indirect", only the first two lines are
>> affected:
>> 
>> “inline object”, “indirect object” (also inline or indirect instance)
>> “inline class”, “indirect class” (also inline or indirect type)
>> 
> 
> It would be nice not to use new terms for old concepts (even if new to
> Java). For alternative terminology originally stemming from similar
> struggles to make such distinctions, see UML "Composition" vs
> "aggregation" (also vs "association"). Wikipedia has some definitions:
> https://en.wikipedia.org/wiki/Class_diagram#Aggregation
> 
> The UML specs say more but behind wall at https://www.omg.org/spec/UML
> 
> -Doug
> 

Re: generic specialization design discussion

[Doug Lea]

On 4/8/19 6:44 PM, John Rose wrote:

> If we move terms around so "value" gets replaced by "inline",
> and "reference" by "indirect", only the first two lines are
> affected:
> 
> “inline object”, “indirect object” (also inline or indirect instance)
> “inline class”, “indirect class” (also inline or indirect type)
> 

It would be nice not to use new terms for old concepts (even if new to
Java). For alternative terminology originally stemming from similar
struggles to make such distinctions, see UML "Composition" vs
"aggregation" (also vs "association"). Wikipedia has some definitions:
https://en.wikipedia.org/wiki/Class_diagram#Aggregation

The UML specs say more but behind wall at https://www.omg.org/spec/UML

-Doug

Re: generic specialization design discussion

[John Rose]

On Apr 8, 2019, at 3:44 PM, John Rose  wrote:
> 
> It also shows that, if we pick a third term like
> "heap", it only applies to regular classes, as an
> antonym for "inline", and to regular objects in
> the same way.

P.S.  In this example, a heap object is not one which is
stored in the heap, but rather which is embodied in its
own heap allocated block, with identity.  Inline objects
can be inlined into the heap, but they are still inline,
no matter where they end up.  An inline object buffered
in its own heap block is not a heap object, because its
value is independent of that particular block; it can be
moved anywhere without losing any part of its value.

There's nothing too special about the word "heap".
It's just doing the job of marking a class or object for
which the placement in the heap, with its own identity,
is a key part of the definition of the object's value.

So, “identity object”, “identity class” would be just
as correct, and maybe less confusing.  Or "top-level
object"?  Or "always-indirect object"?  "Faraway object"?

What we had before was "reference object", where "reference"
as a noun means one thing, and as an adjective means
something related but subtly different.

Re: generic specialization design discussion

[John Rose]

On Apr 8, 2019, at 9:50 AM, Brian Goetz  wrote:
> 
> The slide deck contains a list of terminology.  

FTR here's the relevant slide:

> “value object”, “reference object” (also value or reference instance)
> “value class”, “reference class” (also value or reference type)
> “interface class” (Object = honorary interface)
> object, class, reference: non-specific (non-primitives; ref. can be null)
> value: non-specific (includes all object references, null, all primitives)
> name (class, member), descriptor (field or method)
> resolution: a stable mapping from name to metadata (or error)
> “class template”, “method template” (even “field template”)
> “specialized class” (= "species" for short), “specialized method”
> generic parameter, hole (in template), variance (depends on hole)

If we move terms around so "value" gets replaced by "inline",
and "reference" by "indirect", only the first two lines are
affected:

“inline object”, “indirect object” (also inline or indirect instance)
“inline class”, “indirect class” (also inline or indirect type)

An inline object is inherently inline, even if it is (at the moment)
being referenced by a physical indirection.  An indirect object
is *always* referenced by a physical indirection.

I think we also want to point out (at least in the JVMS) that
the inline/indirect distinction applies to variables as well as
to objects and classes.

“inline variable”, “indirect variable” (parameter, return value, element, 
field, local)

There is a key bit of slippage here, where the terms don't
always line up exactly, nor do they vary freely.  You can
have any of the three but not the fourth:

an indirect variable of an indirect class
an inline variable of an inline class
an indirect variable of an inline class

At this point, we can also point out that interface classes
always have indirect variables.  Also, V? can be an indirect
type where V is an inline type.

This slippage suggests that we might try for an extra term
(or a distinct pair of terms parallel to indirect/inline) which
can apply solely to variables, or to objects, or to classes.
For example, adding "heap" instead of "indirect" for classes:

“inline object”, “heap object” (also inline or heap instance)
“inline class”, “heap class”
"inline type", "indirect type" (heap classes always indirect types)
“inline variable”, “indirect variable” (parameter, return value, element, 
field, local)

Choices for variables:
an indirect variable of a heap class
an indirect variable of an inline class
an inline variable of an inline class

Heap classes are always indirect types.
The natural type of an inline class is an inline type.
But an inline class has (may have?) an associated indirect type.
An interface class is always an indirect type.

This exercise appears to show that "indirect" and
"inline" are principally distinctions between variables
and their types, and only secondarily distinctions
between classes and their objects/instances.

(Variables have more degrees of freedom than
objects, because variables *view* objects, and
a single object can have several views.  We already
saw this with volatile/final/regular and now also
with inline/indirect.)

It also shows that, if we pick a third term like
"heap", it only applies to regular classes, as an
antonym for "inline", and to regular objects in
the same way.

BTW, I think primitives could be thought of as
inline types.  But not inline classes, until we invent
such things in LW200.

Re: generic specialization design discussion

[John Rose]

> ...
> - use via the Object type or an interface (they are indirect)
> - signature compatibility with existing APIs (Optional, LDT)
> - atomic updates (volatile variables)
> - forced nullability of null-hostile classes (ZDV?)
> - permission to load the class later (breaking bootstrap cycles)
> - option to translate recursive value types (requires an indirection)
> - fine control over object layout (when you prefer sharing to flattening)
> - fine control over object API (when you prefer heap buffering to 
> scalarization)

BTW, one reason I like "indirect" is that it is a relatively
unused term in the JVMS, and so can be used to indicate
the new distinction between new flat/scalar and old
"just a pointer", a distinction which gives rise to so many
subtle effects, such as those I just listed.

Using the old words "reference" and "value" for this runs
up against previous existing uses of those words in the JVMS.

Brian and I toyed briefly with the idea of promoting the word
"pointer" (from its mysterious source in NPE) to document the
new distinction, and also the term "address" or "machine address".
"Indirection" won out, for me at least, because it is less concrete.

I also prefer term "indirection" because of its fame as a problem
solver.  It is proverbial that you can solve any problem by adding
another indirection.  (What kind of problem?  See list above!)

https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering

So, in our world, the technical term "indirection" can mean
"What we've always done in the JVM to solve various problems
by adding abstraction to variables."   In contrast to inlining,
which is "What we now do in the JVM to solve other various
problems by breaking abstraction in other variables."

For the JVM an "indirect" variable will be a pointer, a machine
address.  (But perhaps a compressed one!)  The JVM will hide
the details, but the abstraction will be available to solve
those problems which require "another indirection".

Re: generic specialization design discussion

[Remi Forax]

in that case, direct class ? 

Rémi 

> De: "Brian Goetz" 
> À: "Kevin Bourrillion" 
> Cc: "valhalla-spec-experts" 
> Envoyé: Lundi 8 Avril 2019 22:45:46
> Objet: Re: generic specialization design discussion

> And the opposite of “inline” is “indirect”. ref, interface, and null-adjoined
> types are _indirect_. Indirect classes are passed by pointer, do not get
> flattened, get erased, are nullable.

>> On Apr 8, 2019, at 4:20 PM, Brian Goetz < [ mailto:brian.go...@oracle.com |
>> brian.go...@oracle.com ] > wrote:

>> Refining this:

>> - inline classes are inlinable (duh)
>> - reference classes, interfaces, and nullable-projections of zero-default 
>> inline
>> classes are not inlinable

>> (We later use these to say: Instantiation of generics with non-inlinable 
>> types
>> are erased.)

>> That seems not terrible, except for the “nullable projection of zero-default
>> inline classes” part, which is both a mouthful and has “inline” in it. 
>> Perhaps
>> calling these something like “null-adjoined types” (to reflect the fact that
>> we’re cramming a null into a type whose value set doesn’t naturally contain
>> null) makes that slightly better. So:

>> - inline classes are inlinable
>> - reference classes, interfaces, and null-adjoined types are not inlinable

>>> On Apr 8, 2019, at 3:06 PM, Brian Goetz < [ mailto:brian.go...@oracle.com |
>>> brian.go...@oracle.com ] > wrote:

>>> A related issue is that we want a word for describing which types are 
>>> routinely
>>> flattened in layouts, and specialized in generics (the criteria are the 
>>> same).
>>> Currently:

>>> - References and nullable projections of values (V?) are erased and not
>>> flattened
>>> - Values (zero-default and null-default) are specializable and flattenable

>>> (This thread is for terminology; if you have questions about the above 
>>> claims,
>>> make a new thread, or better, wait for the more detailed writeup explaining 
>>> why
>>> this is.)

>>> We need words for these two things too.

>>>> On Apr 8, 2019, at 2:58 PM, Brian Goetz < [ mailto:brian.go...@oracle.com |
>>>> brian.go...@oracle.com ] > wrote:

>>>> Yes, that’s a promising direction. And this is surely the motivation why 
>>>> the C#
>>>> folks picked “struct”; they wanted to carry the connotation that this is a
>>>> structure that is inlined. Problem is, the word “struct” is already so 
>>>> heavily
>>>> polluted by what it means in C. So perhaps something like:

>>>> inline class V { … }

>>>> This says than a V can be inlined into things that contain a V — other 
>>>> classes
>>>> and arrays. It also kind of suggests that this thing has no intrinsic 
>>>> identity.

>>>> A possible downside of this choice is that one might mistake it for 
>>>> meaning “its
>>>> methods are inlined”. Which is actually a little true, in that the methods 
>>>> are
>>>> implicitly static and therefore more amenable to dynamic inlining. So that
>>>> might actually be OK.

>>>> Others?

>>>>> On Apr 8, 2019, at 2:25 PM, Kevin Bourrillion < [ 
>>>>> mailto:kev...@google.com |
>>>>> kev...@google.com ] > wrote:

>>>>> I'd suggest the name should in some way allude to the inline/compact/flat 
>>>>> memory
>>>>> layout, because that is the distinguishing feature of these new things 
>>>>> compared
>>>>> to anything else you can do in Java. And it is what people should be 
>>>>> thinking
>>>>> about as they decide whether a new class should use this.

>>>>> On Mon, Apr 8, 2019 at 10:02 AM Brian Goetz < [ 
>>>>> mailto:brian.go...@oracle.com |
>>>>> brian.go...@oracle.com ] > wrote:

>>>>>> The slide deck contains a list of terminology. I’d like to posit that 
>>>>>> the most
>>>>>> confusion-reducing thing we could do is come up with another word for 
>>>>>> value
>>>>>> types/classes/instances, since the word “value” is already used to 
>>>>>> describe
>>>>>> primitives and references themselves. This is a good time to see if 
>>>>>> there are
>>>>>> better names available.

>>>>>> So for this thread only, we’re turning on the syntax light t

Re: generic specialization design discussion

[John Rose]

I like this, FTR.

Note also that inline classes *may* be passed by indirection,
while indirect classes *must*.  The inline guys have new
capabilities, plus the old ones.

Why would you *want* to represent an inline-capable class
with an indirection?  Good question.  Any of the following
can be a reason to do so:

- use via the Object type or an interface (they are indirect)
- signature compatibility with existing APIs (Optional, LDT)
- atomic updates (volatile variables)
- forced nullability of null-hostile classes (ZDV?)
- permission to load the class later (breaking bootstrap cycles)
- option to translate recursive value types (requires an indirection)
- fine control over object layout (when you prefer sharing to flattening)
- fine control over object API (when you prefer heap buffering to scalarization)

These are all factors we take for granted with Java references today.
They become optional with inline classes.

An "inline class" would more precisely be an "inlinable class",
but doesn't it feel overly pedantic to use the precise term?

So I like "inline class", with the caveat that the first five
minutes of training requires somebody to say something
like, "An inline class can flattened in memory or scalarized
across APIs.  It can also be manipulated indirectly like any
class."

(Note that C++ does something vaguely similar:  A function
marked "inline" can be used indirectly, by taking its address.
The "inline" modifier does not *forbid* indirect use.) 

— John

On Apr 8, 2019, at 1:45 PM, Brian Goetz  wrote:
> 
> And the opposite of “inline” is “indirect”.  ref, interface, and 
> null-adjoined types are _indirect_.  Indirect classes are passed by pointer, 
> do not get flattened, get erased, are nullable.  
> 

Re: generic specialization design discussion

[Brian Goetz]

And the opposite of “inline” is “indirect”.  ref, interface, and null-adjoined 
types are _indirect_.  Indirect classes are passed by pointer, do not get 
flattened, get erased, are nullable.  

> On Apr 8, 2019, at 4:20 PM, Brian Goetz  wrote:
> 
> Refining this: 
> 
>  - inline classes are inlinable (duh)
>  - reference classes, interfaces, and nullable-projections of zero-default 
> inline classes are not inlinable
> 
> (We later use these to say: Instantiation of generics with non-inlinable 
> types are erased.)
> 
> That seems not terrible, except for the “nullable projection of zero-default 
> inline classes” part, which is both a mouthful and has “inline” in it.  
> Perhaps calling these something like “null-adjoined types” (to reflect the 
> fact that we’re cramming a null into a type whose value set doesn’t naturally 
> contain null) makes that slightly better.  So:
> 
>  - inline classes are inlinable 
>  - reference classes, interfaces, and null-adjoined types are not inlinable
> 
> 
> 
> 
>> On Apr 8, 2019, at 3:06 PM, Brian Goetz > > wrote:
>> 
>> A related issue is that we want a word for describing which types are 
>> routinely flattened in layouts, and specialized in generics (the criteria 
>> are the same).  Currently:
>> 
>>   - References and nullable projections of values (V?) are erased and not 
>> flattened
>>   - Values (zero-default and null-default) are specializable and flattenable
>> 
>> (This thread is for terminology; if you have questions about the above 
>> claims, make a new thread, or better, wait for the more detailed writeup 
>> explaining why this is.)
>> 
>> We need words for these two things too.  
>> 
>>> On Apr 8, 2019, at 2:58 PM, Brian Goetz >> > wrote:
>>> 
>>> Yes, that’s a promising direction.  And this is surely the motivation why 
>>> the C# folks picked “struct”; they wanted to carry the connotation that 
>>> this is a structure that is inlined.  Problem is, the word “struct” is 
>>> already so heavily polluted by what it means in C.  So perhaps something 
>>> like:
>>> 
>>> inline class V { … }
>>> 
>>> This says than a V can be inlined into things that contain a V — other 
>>> classes and arrays.  It also kind of suggests that this thing has no 
>>> intrinsic identity.  
>>> 
>>> A possible downside of this choice is that one might mistake it for meaning 
>>> “its methods are inlined”.  Which is actually a little true, in that the 
>>> methods are implicitly static and therefore more amenable to dynamic 
>>> inlining.  So that might actually be OK.  
>>> 
>>> Others?
>>> 
 On Apr 8, 2019, at 2:25 PM, Kevin Bourrillion >>> > wrote:
 
 I'd suggest the name should in some way allude to the inline/compact/flat 
 memory layout, because that is the distinguishing feature of these new 
 things compared to anything else you can do in Java. And it is what people 
 should be thinking about as they decide whether a new class should use 
 this.
 
 
 On Mon, Apr 8, 2019 at 10:02 AM Brian Goetz >>> > wrote:
 The slide deck contains a list of terminology.  I’d like to posit that the 
 most confusion-reducing thing we could do is come up with another word for 
 value types/classes/instances, since the word “value” is already used to 
 describe primitives and references themselves.  This is a good time to see 
 if there are better names available.  
 
 So for this thread only, we’re turning on the syntax light to discuss what 
 might be a better name for the abstraction currently known as “value 
 classes”.  
 
 
 
 > On Mar 29, 2019, at 12:08 PM, John Rose >>> > > wrote:
 > 
 > This week I gave some presentations of my current thinking
 > about specializations to people (from Oracle and IBM) gathered
 > in Burlington.  Here it is FTR.  If you read it you will find lots
 > of questions, as well as requirements and tentative answers.
 > 
 > http://cr.openjdk.java.net/~jrose/pres/201903-TemplateDesign.pdf 
 > 
 > 
 > This is a checkpoint.  I have more tentative answers on the
 > drawing board that didn't fit into the slide deck.  Stay tuned.
 > 
 > — John
 
 
 
 -- 
 Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com 
 
>> 
> 

Re: generic specialization design discussion

[Remi Forax]

> De: "Kevin Bourrillion" 
> À: "Brian Goetz" 
> Cc: "valhalla-spec-experts" 
> Envoyé: Lundi 8 Avril 2019 20:25:24
> Objet: Re: generic specialization design discussion

> I'd suggest the name should in some way allude to the inline/compact/flat 
> memory
> layout, because that is the distinguishing feature of these new things 
> compared
> to anything else you can do in Java. And it is what people should be thinking
> about as they decide whether a new class should use this.

immediate class ? 

Rémi 

> On Mon, Apr 8, 2019 at 10:02 AM Brian Goetz < [ mailto:brian.go...@oracle.com 
> |
> brian.go...@oracle.com ] > wrote:

>> The slide deck contains a list of terminology. I’d like to posit that the 
>> most
>> confusion-reducing thing we could do is come up with another word for value
>> types/classes/instances, since the word “value” is already used to describe
>> primitives and references themselves. This is a good time to see if there are
>> better names available.

>> So for this thread only, we’re turning on the syntax light to discuss what 
>> might
>> be a better name for the abstraction currently known as “value classes”.

>>> On Mar 29, 2019, at 12:08 PM, John Rose < [ mailto:john.r.r...@oracle.com |
>> > john.r.r...@oracle.com ] > wrote:

>> > This week I gave some presentations of my current thinking
>> > about specializations to people (from Oracle and IBM) gathered
>> > in Burlington. Here it is FTR. If you read it you will find lots
>> > of questions, as well as requirements and tentative answers.

>>> [ http://cr.openjdk.java.net/~jrose/pres/201903-TemplateDesign.pdf |
>> > http://cr.openjdk.java.net/~jrose/pres/201903-TemplateDesign.pdf ]

>> > This is a checkpoint. I have more tentative answers on the
>> > drawing board that didn't fit into the slide deck. Stay tuned.

>> > — John

> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | [ 
> mailto:kev...@google.com |
> kev...@google.com ]

Re: generic specialization design discussion

[Brian Goetz]

Refining this: 

 - inline classes are inlinable (duh)
 - reference classes, interfaces, and nullable-projections of zero-default 
inline classes are not inlinable

(We later use these to say: Instantiation of generics with non-inlinable types 
are erased.)

That seems not terrible, except for the “nullable projection of zero-default 
inline classes” part, which is both a mouthful and has “inline” in it.  Perhaps 
calling these something like “null-adjoined types” (to reflect the fact that 
we’re cramming a null into a type whose value set doesn’t naturally contain 
null) makes that slightly better.  So:

 - inline classes are inlinable 
 - reference classes, interfaces, and null-adjoined types are not inlinable




> On Apr 8, 2019, at 3:06 PM, Brian Goetz  wrote:
> 
> A related issue is that we want a word for describing which types are 
> routinely flattened in layouts, and specialized in generics (the criteria are 
> the same).  Currently:
> 
>   - References and nullable projections of values (V?) are erased and not 
> flattened
>   - Values (zero-default and null-default) are specializable and flattenable
> 
> (This thread is for terminology; if you have questions about the above 
> claims, make a new thread, or better, wait for the more detailed writeup 
> explaining why this is.)
> 
> We need words for these two things too.  
> 
>> On Apr 8, 2019, at 2:58 PM, Brian Goetz > > wrote:
>> 
>> Yes, that’s a promising direction.  And this is surely the motivation why 
>> the C# folks picked “struct”; they wanted to carry the connotation that this 
>> is a structure that is inlined.  Problem is, the word “struct” is already so 
>> heavily polluted by what it means in C.  So perhaps something like:
>> 
>> inline class V { … }
>> 
>> This says than a V can be inlined into things that contain a V — other 
>> classes and arrays.  It also kind of suggests that this thing has no 
>> intrinsic identity.  
>> 
>> A possible downside of this choice is that one might mistake it for meaning 
>> “its methods are inlined”.  Which is actually a little true, in that the 
>> methods are implicitly static and therefore more amenable to dynamic 
>> inlining.  So that might actually be OK.  
>> 
>> Others?
>> 
>>> On Apr 8, 2019, at 2:25 PM, Kevin Bourrillion >> > wrote:
>>> 
>>> I'd suggest the name should in some way allude to the inline/compact/flat 
>>> memory layout, because that is the distinguishing feature of these new 
>>> things compared to anything else you can do in Java. And it is what people 
>>> should be thinking about as they decide whether a new class should use this.
>>> 
>>> 
>>> On Mon, Apr 8, 2019 at 10:02 AM Brian Goetz >> > wrote:
>>> The slide deck contains a list of terminology.  I’d like to posit that the 
>>> most confusion-reducing thing we could do is come up with another word for 
>>> value types/classes/instances, since the word “value” is already used to 
>>> describe primitives and references themselves.  This is a good time to see 
>>> if there are better names available.  
>>> 
>>> So for this thread only, we’re turning on the syntax light to discuss what 
>>> might be a better name for the abstraction currently known as “value 
>>> classes”.  
>>> 
>>> 
>>> 
>>> > On Mar 29, 2019, at 12:08 PM, John Rose >> > > wrote:
>>> > 
>>> > This week I gave some presentations of my current thinking
>>> > about specializations to people (from Oracle and IBM) gathered
>>> > in Burlington.  Here it is FTR.  If you read it you will find lots
>>> > of questions, as well as requirements and tentative answers.
>>> > 
>>> > http://cr.openjdk.java.net/~jrose/pres/201903-TemplateDesign.pdf 
>>> > 
>>> > 
>>> > This is a checkpoint.  I have more tentative answers on the
>>> > drawing board that didn't fit into the slide deck.  Stay tuned.
>>> > 
>>> > — John
>>> 
>>> 
>>> 
>>> -- 
>>> Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com 
>>> 
> 

Re: generic specialization design discussion

[Brian Goetz]

A related issue is that we want a word for describing which types are routinely 
flattened in layouts, and specialized in generics (the criteria are the same).  
Currently:

  - References and nullable projections of values (V?) are erased and not 
flattened
  - Values (zero-default and null-default) are specializable and flattenable

(This thread is for terminology; if you have questions about the above claims, 
make a new thread, or better, wait for the more detailed writeup explaining why 
this is.)

We need words for these two things too.  

> On Apr 8, 2019, at 2:58 PM, Brian Goetz  wrote:
> 
> Yes, that’s a promising direction.  And this is surely the motivation why the 
> C# folks picked “struct”; they wanted to carry the connotation that this is a 
> structure that is inlined.  Problem is, the word “struct” is already so 
> heavily polluted by what it means in C.  So perhaps something like:
> 
> inline class V { … }
> 
> This says than a V can be inlined into things that contain a V — other 
> classes and arrays.  It also kind of suggests that this thing has no 
> intrinsic identity.  
> 
> A possible downside of this choice is that one might mistake it for meaning 
> “its methods are inlined”.  Which is actually a little true, in that the 
> methods are implicitly static and therefore more amenable to dynamic 
> inlining.  So that might actually be OK.  
> 
> Others?
> 
>> On Apr 8, 2019, at 2:25 PM, Kevin Bourrillion > > wrote:
>> 
>> I'd suggest the name should in some way allude to the inline/compact/flat 
>> memory layout, because that is the distinguishing feature of these new 
>> things compared to anything else you can do in Java. And it is what people 
>> should be thinking about as they decide whether a new class should use this.
>> 
>> 
>> On Mon, Apr 8, 2019 at 10:02 AM Brian Goetz > > wrote:
>> The slide deck contains a list of terminology.  I’d like to posit that the 
>> most confusion-reducing thing we could do is come up with another word for 
>> value types/classes/instances, since the word “value” is already used to 
>> describe primitives and references themselves.  This is a good time to see 
>> if there are better names available.  
>> 
>> So for this thread only, we’re turning on the syntax light to discuss what 
>> might be a better name for the abstraction currently known as “value 
>> classes”.  
>> 
>> 
>> 
>> > On Mar 29, 2019, at 12:08 PM, John Rose > > > wrote:
>> > 
>> > This week I gave some presentations of my current thinking
>> > about specializations to people (from Oracle and IBM) gathered
>> > in Burlington.  Here it is FTR.  If you read it you will find lots
>> > of questions, as well as requirements and tentative answers.
>> > 
>> > http://cr.openjdk.java.net/~jrose/pres/201903-TemplateDesign.pdf 
>> > 
>> > 
>> > This is a checkpoint.  I have more tentative answers on the
>> > drawing board that didn't fit into the slide deck.  Stay tuned.
>> > 
>> > — John
>> 
>> 
>> 
>> -- 
>> Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com 
>> 

Re: generic specialization design discussion

[Brian Goetz]

Yes, that’s a promising direction.  And this is surely the motivation why the 
C# folks picked “struct”; they wanted to carry the connotation that this is a 
structure that is inlined.  Problem is, the word “struct” is already so heavily 
polluted by what it means in C.  So perhaps something like:

inline class V { … }

This says than a V can be inlined into things that contain a V — other classes 
and arrays.  It also kind of suggests that this thing has no intrinsic 
identity.  

A possible downside of this choice is that one might mistake it for meaning 
“its methods are inlined”.  Which is actually a little true, in that the 
methods are implicitly static and therefore more amenable to dynamic inlining.  
So that might actually be OK.  

Others?

> On Apr 8, 2019, at 2:25 PM, Kevin Bourrillion  wrote:
> 
> I'd suggest the name should in some way allude to the inline/compact/flat 
> memory layout, because that is the distinguishing feature of these new things 
> compared to anything else you can do in Java. And it is what people should be 
> thinking about as they decide whether a new class should use this.
> 
> 
> On Mon, Apr 8, 2019 at 10:02 AM Brian Goetz  > wrote:
> The slide deck contains a list of terminology.  I’d like to posit that the 
> most confusion-reducing thing we could do is come up with another word for 
> value types/classes/instances, since the word “value” is already used to 
> describe primitives and references themselves.  This is a good time to see if 
> there are better names available.  
> 
> So for this thread only, we’re turning on the syntax light to discuss what 
> might be a better name for the abstraction currently known as “value 
> classes”.  
> 
> 
> 
> > On Mar 29, 2019, at 12:08 PM, John Rose  > > wrote:
> > 
> > This week I gave some presentations of my current thinking
> > about specializations to people (from Oracle and IBM) gathered
> > in Burlington.  Here it is FTR.  If you read it you will find lots
> > of questions, as well as requirements and tentative answers.
> > 
> > http://cr.openjdk.java.net/~jrose/pres/201903-TemplateDesign.pdf 
> > 
> > 
> > This is a checkpoint.  I have more tentative answers on the
> > drawing board that didn't fit into the slide deck.  Stay tuned.
> > 
> > — John
> 
> 
> 
> -- 
> Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com 
> 

Re: generic specialization design discussion

[Brian Goetz]

The slide deck contains a list of terminology.  I’d like to posit that the most 
confusion-reducing thing we could do is come up with another word for value 
types/classes/instances, since the word “value” is already used to describe 
primitives and references themselves.  This is a good time to see if there are 
better names available.  

So for this thread only, we’re turning on the syntax light to discuss what 
might be a better name for the abstraction currently known as “value classes”.  



> On Mar 29, 2019, at 12:08 PM, John Rose  wrote:
> 
> This week I gave some presentations of my current thinking
> about specializations to people (from Oracle and IBM) gathered
> in Burlington.  Here it is FTR.  If you read it you will find lots
> of questions, as well as requirements and tentative answers.
> 
> http://cr.openjdk.java.net/~jrose/pres/201903-TemplateDesign.pdf
> 
> This is a checkpoint.  I have more tentative answers on the
> drawing board that didn't fit into the slide deck.  Stay tuned.
> 
> — John