Re: class, type, instance, object, value

[John Rose]

On Jul 12, 2017, at 6:20 AM, Karen Kinnear  wrote:
> 
> 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 
*If* the JLS user model of Valhalla values associates a derived "box" with a 
value,
something like Integer is associated with int, *then* a value class derives both
the plain value (the primary thing) and the box (a secondary thing).

We are *not* certain that boxes are necessary in L-world.  I think they are 
forced
on us in U-world.  This is an advantage of L-world, where L-types are at the top
and Q-types just "sneak in".

> 2) classfile - marked via ACC_VALUE, from could derive a value class and a 
> boxed class
Yes, I meant that.
> 3) constant_pool entry - at which we want a way to distinguish the two types
Yes.  A common class with different kind/mode markings, Q vs. L vs. maybe U,
but all the same class.
> 4) vm internal metadata - again distinguish two types
Implementor's choice on that one.
> 5) java level use - at which I am assuming we will have a way to distinguish 
> a value class and a boxed value
OK, I thought that's what you were asking in 1.

Key principle:  One source construct = one class.  (Inner classes are nested
source constructs which allow several classes to be defined by one file;
that's something the JVM can usually ignore, or model via nestmates.)
> I believe Dan’s use of the term value class is for the unboxed value.
There's one class, so if the box is defined from the same one central class,
then I'm OK with Dan's term "value class" for the *one class* that defines
*both* values and boxes.

(I'm discouraging us from using the word "class" to refer to individual values
of the object.  We don't say "print me a string class", we say "print me a
string value" or (maybe) "print me an string instance".  I don't think that's
how Dan was using his terms, but just in case…)
> I think we want to explicitly call out boxed value.
Indeed.  But there is no need to have multiple classes to describe both
values and their boxes; for any given value class it all flows from that
one single value class.  (I suspect we are in violent agreement here.)
> - 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.

Not if we do what Brian calls "crasses".  For example, if we make a "crass" of 
java.util.List,
then that reflects a "something" (which I call "species") that combines the 
*class* java.util.List
with the template argument "int".  The result of that *should not* be called a 
"class", because
that will cause confusion as folks scurry around trying to find the source code 
and/or classfile
for that "something", and find only plain old java.util.List.

So the term "class" should refer to "what comes out of a classfile", and/or an 
occurrence
in Java code of a class/interface/enum definition.

A "crass" is a java.lang.Class which refers not just to java.util.List (which 
is a perfectly
normal class mirror like today's) but to the *species* List.  If we do 
"crasses" it
will be a carefully weighed decision to overload the legacy type 
java.lang.Class to
mirror not just true Java classes (and interfaces and enums) but *also* it will 
mirror
species which are derived from a template.  In this framework, a *box* looks 
like
another variation stamped out of the original class.

If we don't do "crasses" (the "r" stands for "runtime quasi-class type", 
approximately),
then we will need new kinds of mirrors, to mirror not the proper classes (and 
interfaces
and enums) but to mirror the species which are created by specializing 
templates,
and/or the boxes (if we do them) which represent the identity-laden variants of
identity-free values.

> Even if we use a name to find a class-for-the-box vs. 
> class-for-the-value, the java.lang.Class itself
> would be unique, wouldn’t it?

Hmmm… If we do both "crasses" and boxes then there could be a proper class
mirror for a real value class like java.math.FloatComplex, and then a "crass"
mirror for its identity-laden box, which is not Q-FloatComplex but 
L-FloatComplex.

If we do L-world (see forthcoming message) we can avoid the box, but then
we might template the complex numbers, and thus have many mirror "crasses"
for the various species Complex, Complex, etc.

> 
> thanks,
> Karen
> 

Re: class, type, instance, object, value

[Remi Forax]

Usually the difference between a class and a type is more runtime vs compile 
time.
A type exist at compile time, a class exist at runtime.
A type at compile time which is propagated as a class at runtime is a reified 
type, etc...

Rémi

- Mail original -
> De: "John Rose" <john.r.r...@oracle.com>
> À: "Bjorn B Vardal" <bjorn...@ca.ibm.com>
> Cc: valhalla-spec-experts@openjdk.java.net
> Envoyé: Lundi 26 Juin 2017 20:41:49
> Objet: Re: class, type, instance, object, value

> On Jun 26, 2017, at 5:16 AM, Bjorn B Vardal <bjorn...@ca.ibm.com> wrote:
>> 
>>> > 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)
>>  
>> If you want to resolve this ambiguity, I've been referring to the former as a
>> "value typed field" and the latter as a "value field".
>>  
> 
> Yes, that can work where the context is strong enough to keep the reader 
> alert.
> But a single letter 'd' is a slender hook to hang your meaning on, and its
> *absence* is even
> more delicate.  Unless the context makes it very clear, I'd want to say "value
> class field",
> or "field in a value" (ellipsis for "value class") instead of "value field" as
> you suggest.
> 
> (Remember, classes define fields, and then they show up in a type's API 
> surface.
> So you can usually clarify "field of some type" to "field in some class" or
> "field of
> that type's class".  And on the other hand "field with that type" or even 
> "field
> of that
> type".  The word "of" is treacherous here, and "in" and "with" are more
> reliable.)
> 
> In some cases you have to spit out even more words to be safe: "field within
> value type",
> "field that is a member of a value type", "field declared as a value type",
> "field whose type
> is a value type", etc., etc.  Some of those circumlocutions benefit from
> ellipsis (which is
> "value" standing for "value type" with the "type" clear from context).
> 
> Note that Java is already full of small ambiguities like this:  "Interface
> field", "inner class field",
> "wrapper type field".  Perhaps we could lean harder on the class-vs-type
> distinction:  "Field of
> an interface type" is a "field typed as an interface (type)" whereas "Field of
> an interface class"
> is a "field declared in a class which defines an interface".
> 
> (But we don't say "interface class" at this point, and it would be hard to get
> folks to accept it,
> even though it would clarify existing ambiguities about "class" meaning "class
> or interface or
> enum" in many places.)
> 
> — John

Re: class, type, instance, object, value

[Karen Kinnear]

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

Re: class, type, instance, object, value

[John Rose]

On Jun 26, 2017, at 5:16 AM, Bjorn B Vardal  wrote:
> 
>> > 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)
>  
> If you want to resolve this ambiguity, I've been referring to the former as a 
> "value typed field" and the latter as a "value field".
>  

Yes, that can work where the context is strong enough to keep the reader alert.
But a single letter 'd' is a slender hook to hang your meaning on, and its 
*absence* is even
more delicate.  Unless the context makes it very clear, I'd want to say "value 
class field",
or "field in a value" (ellipsis for "value class") instead of "value field" as 
you suggest.

(Remember, classes define fields, and then they show up in a type's API surface.
So you can usually clarify "field of some type" to "field in some class" or 
"field of
that type's class".  And on the other hand "field with that type" or even 
"field of that
type".  The word "of" is treacherous here, and "in" and "with" are more 
reliable.)

In some cases you have to spit out even more words to be safe: "field within 
value type",
"field that is a member of a value type", "field declared as a value type", 
"field whose type
is a value type", etc., etc.  Some of those circumlocutions benefit from 
ellipsis (which is
"value" standing for "value type" with the "type" clear from context).

Note that Java is already full of small ambiguities like this:  "Interface 
field", "inner class field",
"wrapper type field".  Perhaps we could lean harder on the class-vs-type 
distinction:  "Field of
an interface type" is a "field typed as an interface (type)" whereas "Field of 
an interface class"
is a "field declared in a class which defines an interface".

(But we don't say "interface class" at this point, and it would be hard to get 
folks to accept it,
even though it would clarify existing ambiguities about "class" meaning "class 
or interface or
enum" in many places.)

— John

Re: class, type, instance, object, value

[John Rose]

On Jun 25, 2017, at 7:17 PM, John Rose  wrote:
> 
> object: (ambig.) a reference to an object instance OR context-dependent 
> ellipsis for value type/class/instance

s/ellipsis for value/ellipsis for object/