John,
Thank you for writing this up. Couple of questions/comments.
- The class of a boxed value is the value class. (Thus each value class
derives at least two types.)
This one confuses me. I am not sure what you are referring to.
1) source: declaration - declared as a value class
2) classfile - marked via ACC_VALUE, from could derive a value class and a
boxed class
3) constant_pool entry - at which we want a way to distinguish the two types
4) vm internal metadata - again distinguish two types
5) java level use - at which I am assuming we will have a way to distinguish a
value class and a boxed value
I believe Dan’s use of the term value class is for the unboxed value.
I think we want to explicitly call out boxed value.
- A "java.lang.Class" is usually a reference to class metadata, but not
necessarily unique.
There's wiggle room here for class-for-the-box vs. class-for-the-value, and
int.class.
We don't allow java.lang.Class to constrain other uses of the term "class".
- When clarity is at risk, we can say "class mirror" rather than just "Class".
I’m not sure what you mean here by “not necessarily unique”. Perhaps that is
because for me a java.lang.Class
is always a mirror, i.e. a reflection of the vm’s internal representation for
the unique class.
Even if we use a name&mode to find a class-for-the-box vs. class-for-the-value,
the java.lang.Class itself
would be unique, wouldn’t it?
thanks,
Karen
> On Jun 25, 2017, at 10:17 PM, John Rose <john.r.r...@oracle.com> wrote:
>
> So, I'm writing more and more documentation that discusses
> objects and primitives while bringing values into the mix.
>
> What seems right to me is that we allow the terms "class", "type",
> and "instance" to symmetrically cover both legacy object types
> and new value types. We should continue to use the word "value"
> but be careful about distinguishing its overloadings, especially
> its role as an absolute noun vs. its role as an adjective.
>
> We should tolerate asymmetries that arise from the reference vs.
> value distinction, and from box types which arise from value classes.
>
> Summary:
>
> Classes = Object Classes <+> Value Classes
> Instances = Object Instances <+> Value Instances
> Object Instances = instances of Object Classes <+> boxes of Value Instances
> Reference Values = Object Instances <+> null
> Values (noun) = Reference Values <+> Value Instances <+> Primitives
>
> (…where <+> denotes disjoint union)
>
> Details:
>
> - A "class" is at root metadata describing a type or implementation.
> (It has API surface and/or implementation: super types, methods, fields,
> etc.)
> - An "instance" is derived from a class and/or conforms to that class's API.
> - An instance of an "object class" (or "object type") is an "object instance"
> (or just "object").
> - An instance of an "value class" (or "object value") is a "value instance"
> (or just "value" if context allows).
> - When clarity is at risk, we can call a value class or value instance a
> "non-object class" or "non-object value".
> - Because object instances are referred to by reference, a variable bound to
> one is a "reference".
> (References can be to object instances, to boxes of value instances, or to
> the unique reference null.)
> - A reference can also take "null" ("the null reference") as a value.
> - References, primitives, and value instances are all "values" since they are
> passed by value.
> - An instance of a "value class" is a "value instance" or (when clarity is
> not at risk) just a "value".
> - Because value instances are referred to "by value", a variable bound to one
> is just a "value".
> (When clarity is at risk, such a variable can be called a "pure value" or
> "non-reference".)
>
> Ambiguity:
>
> - The term "value" used as a noun can refer to the contents of a variable:
> reference, primitive, or value instance.
> - The term "value" used as an adjective distinguishes a class, type, or
> instance from the "object" version.
> - The term "value" can abbreviate "value instance"; context must clear this
> usage from ambiguity.
> - Thus, the term "value" must always be used in a context which resolves it
> ambiguity.
> (We could coin a new term to avoid ambiguity, but the meaning of "value"
> perfect, so let's keep it.)
> - Sometimes when we say "value type" we really mean "non-object type", and
> expect primitives to be included.
> - As part of fit-and-finish of Value Types we will give the primitives a
> comfortable seat at the table.
> (Perhaps we can cleverly ret-con primitive types as value types, and their
> wrappers as boxes thereof.)
>
> Boxing, buffering, identity:
>
> - A value can be "boxed" into an object. Such an object can be "unboxed"
> back into its value.
> - Boxed values are true objects, with object type.
> - The class of a boxed value is the value class. (Thus each value class
> derives at least two types.)
> - A value (of any sort) does not have identity, only the object instance
> under a non-null reference does.
> - A "boxed value" (or "value is an object has identity, since it is an
> object instance.
> - If an implementation uses pointer indirection to access a value, we say it
> is stored in a "buffer".
> (This avoids confusion, since boxes are objects but buffers are not
> necessarily objects.)
> - Buffers are invisible to the user, except perhaps via performance effects,
> or trusted APIs like Unsafe.
> - Buffers can be on the stack, the heap, or anywhere else in memory.
> - Boxes can secretly serve as buffers.
>
> False friends:
>
> - A "java.lang.Class" is usually a reference to class metadata, but not
> necessarily unique.
> There's wiggle room here for class-for-the-box vs. class-for-the-value, and
> int.class.
> We don't allow java.lang.Class to constrain other uses of the term "class".
> - When clarity is at risk, we can say "class mirror" rather than just "Class".
> - Similar point for "CONSTANT_Class" in the constant pool schema. Relatively
> few folks
> are conscious of this term anyway.
> - "Object-oriented" programming usually refers to some combination of
> classes with reference-based polymorphism. Value types are object
> oriented, even though their reference-based polymorphism is limited to
> interfaces. Also they are squarely based on classes.
>
> Glossary:
>
> value type: a type which may be used without an accompanying reference (i.e.,
> no intrinsic reference identity or aliasing)
> value class: a code entity which defines a value type
> value instance: a possible value (at runtime) of a variable of value type,
> derived from a value class
> value field: (ambig.) field whose type is a value type (in any kind of class)
> OR a field in a value class (of any type)
> value parameter: (ambig.) a parameter whose type is a value type OR a
> parameter, with emphasis on by-value transmission
> value: (ambig.) a reference, value instance, or primitive OR
> context-dependent ellipsis for value type/class/instance
>
> object type: a type without references (i.e., no reference identity, no
> aliasing)
> object class: a code entity which defines an object type
> object instance: a possible value (at runtime) of a non-null variable of
> reference type
> object field/parameter: (ambig., see above)
> object: (ambig.) a reference to an object instance OR context-dependent
> ellipsis for value type/class/instance
>
> box type: an object type derived from a value class
> box instance: a possible value (at runtime) of a non-null variable of box type
> box: (ambig., see above)
>
> instance/class/type: (ambig., see above)
>
