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

Reply via email to