[[Class]] Property of Host Object

[Allen Wirfs-Brock]

>> The more important issue is our intent regarding the definitions of "host" and "native" objects.

First regarding, alert in IE.  Historically it is what it is and nobody should make any assumptions concerning the future based upon previous versions of IE or what they have observed so for in IE9 preview builds.  I don't think there is any disagreement that the [[class]] of alert should be 'Function'. However, if you want to pin that down in a standard then WebIDL is probably the place you need to do it.

I agree that there is still a lack of clarity in the ES5 spec. regarding the definition of "host object" and the distinction between "host" and "native" objects.  The ES5 spec. is better than the previous editions in this regard but could still be improved.  This isn't an error that can be corrected by an errata but it is something that can be improved by rewrites in future editions. In particular, the spec. is fuzzy about whether the sets of native and host objects are disjoint.

Here is what I believe is the intent:

Native Object: as stated in 4.3.6, an object that fully implements the object semantics defined by the Ecma-262 specification. Such objects might be built-in, user defined using ECMAScript code, or provided by the host  (and that presumably includes libraries of native objects that are accessed via host defined facilities).  The important point and the characteristic that makes then "native" is that they fully conform to the standards semantics for objects.

Host object: as stated in 4.3.8, an object supplied by the host environment.  If a host object fully implements the standard object semantics then it is also a native object (hence native and host objects are not two disjoint sets).  However, host objects are not required to implement this standard semantics.  In addition, the note to 4.3.8 says that any object that isn't native (ie, doesn't implement standard object semantics) is a host object.

So essentially, they are two kinds of host objects: native host objects and non-native host objects.  The spec. doesn't explicitly talk about native host objects because their hostness is semantically irrelevant if they are also native.  Hence, when the spec. talks about "host objects" in most cases it is really talking about non-native host objects in order to impose specific sematic constraints upon them.  I believe that in most cases in the ES5 spec,  "host object" should be read as meaning "non-native host object".

By these terms, an  Array instance (or other built-in object "class" instance) can be a host object but if it is, it must be a native host object. That is, it most fully implement the specific semantics for that kind of object.

Allen

From: Mark S. Miller [mailto:erights at google.com]
Sent: Sunday, July 18, 2010 9:52 AM
To: Allen Wirfs-Brock
Cc: Garrett Smith; es5-discuss at mozilla.org; es-discuss
Subject: Re: [[Class]] Property of Host Object

Hi Allen, that answers the "must is be a String?" issue, thanks.

The more important issue is our intent regarding the definitions of "host" and "native" objects. What is your memory of this issue? How well do you think the spec reflects this intent?
On Sun, Jul 18, 2010 at 7:31 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com<mailto:Allen.Wirfs-Brock at microsoft.com>> wrote:
Table 8, section 8.6.2
Internal Property: [[Class]]
Value Type Domain: String
Description: A String value indicating a specification defined classification of objects

Allen

From: es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org> [mailto:es-discuss-bounces at mozilla.org<mailto:es-discuss-bounces at mozilla.org>] On Behalf Of Mark S. Miller
Sent: Saturday, July 17, 2010 12:54 PM
To: Garrett Smith
Cc: es5-discuss at mozilla.org<mailto:es5-discuss at mozilla.org>; es-discuss
Subject: Re: [[Class]] Property of Host Object

In short, I largely agree with you about the language in the ES5 spec text. My interpretation of that text derives in large part from my memories of the conversations that led up to it, and my sense of the intent we were trying to capture. In the absence of that context, I would probably arrive at the same reading of ES5 that you have.

At this point, I will wait until others who participated in those conversations weigh in and state their sense of our agreed intent. Once we understand what agreed intent there actually was, we can proceed from there.

On Sat, Jul 17, 2010 at 12:17 PM, Garrett Smith <dhtmlkitchen at gmail.com<mailto:dhtmlkitchen at gmail.com>> wrote:
On 7/17/10, Mark S. Miller <erights at google.com<mailto:erights at google.com>> wrote:
> [+es5-discuss as a possible errata issue arises below]
>
>
> On Sat, Jul 17, 2010 at 12:37 AM, Garrett Smith
> <dhtmlkitchen at gmail.com<mailto:dhtmlkitchen at gmail.com>>wrote:
>
>> On 7/16/10, Mark S. Miller <erights at google.com<mailto:erights at google.com>> wrote:
>> > On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith
>> > <dhtmlkitchen at gmail.com<mailto:dhtmlkitchen at gmail.com>>wrote:
>> >
>> >> I have a question reqarding [[Class]] property as defined In ES5:
>> >>
>> >> | The value of the [[Class]] internal property of a host object
>> >> | may be any String value except one of "Arguments", "Array",
>> >> | "Boolean", "Date", "Error", "Function", "JSON", "Math", "Number",
>> >> | "Object", "RegExp", and "String"
>> >>
>> >> May it be something other than a string value? Or must it be a string
>> >> value?
>> >>
>> >
>> > It must be a string value.
>> >
>>
>> The specification says "may".
>>
>
> Ah. I see the ambiguity. "may" there is modifying "any". It should probably
> have been stated:
>
>     ...must be a String value and may be any String value except...
>
> In reviewing the document, the possibility that text would allow non-String
> [[Class]]es had not occurred to me. Now that you point it out, and can see
> some reasons why we might want to leave the current text alone and allow
> non-String [[Class]]es.
>
I don't.

[[Class]] must be a string value. If the [[Class]] property is absent,
what happens when the object is supplied to Object.prototype.toString?
TypeError. Why not avoid that possibility and require host object to
have [[Class]] be a string value?

>
>
>>
>> >
>> >>
>> >> Why must a host object's class be none of the built-in classes listed?
>> >>
>> >
>> > So that the [[Class]] property serve as a reliable nominal type check
>> > for
>> > the contract that the other internal properties and methods satisfy.
>> > This
>> is
>> > used primarily within the spec itself. Previously, it wasn't clear what
>> was
>> > meant when the spec said, for example, "if F is a function". Now we
>> clearly
>> > say "if the [[Class]] of F is 'Function' " if that's what we mean.
>> >
>>
>> I think I see the problem.
>>
>> What you really want to say there is:
>>
>> |  The value of the [[Class]] internal property of any non-native host
>> |  object must be any String value except one of...
>>
>
> Saying "non-native" and "host" together is redundant. Although the language
> of 4.3.6 and 4.3.8 is not as clear as it should be, I read these as stating
> that all EcmaScript objects are either host or native. No object can be both
> host and native. And no object can be neither host nor native.
>
It is not redundant. Repeating what was written in my last message:

|  While the specification does not preclude the possibility that a host
|  object may be implemented with native semantics, it nonetheless
|  defines a host object:
I understand that the values for [[Class]] are used internally by the
specification. One example of that is Array.isArray(x), where the
[[Class]] property is used internally. Another example is behavior for
`JSON` reviver.

The specification allows for two types of host objects:
 * host objects as native objects
 * host objects as not native objects (does not use native semantics)