[[Class]] Property of Host Object

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[[Class]] Property of Host Object

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

Why must a host object's class be none of the built-in classes listed?
Implementations don't agree; when calling `Object.prototype.toString`
with a host object, the result will often be one of those values.

  Object.prototype.toString.call(alert);

results either "[object Function]" or "[object Object]". That behavior
is allowed in ES3, but why not in ES5? ES5 seems to defy what most (if
not all) implementations do there.

Some host objects including `alert` are implemented as a native
ECMAScript objects (`alert instanceof Function`). In that case, the
[[Class]] property should be "Function".

However according to ES5 specs, any host object must not be withing
the set of values that are not allowable and so the assertion could be
made that if any object has a [[Class]] that is one of those values,
then the object is not a host object. An `isHostObject` method could
be written using a RegExp:

// DO NOT USE
var _toString = Object.prototype.toString,
    nativeClasses =
/Array|Boolean|Date|Error|Function|JSON|Math|Number|Object|RegExp|String/;

function isHostMethod(m) {
  return !nativeClasses.test(.call(m));
}

However, we know that won't hold true in many cases more than just `alert`.

Is the specification wrong here or what am I missing?

Garrett
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Mark S. Miller-2
On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith <[hidden email]> 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.
 

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.

But it is also used from JS. Host objects are exempt from most of the specific behaviors specified for specific kinds of native objects. Were a host object to be able to allege to be a kind of native object without behaving as that kind of native object behaves, that would be bad.

 
Implementations don't agree; when calling `Object.prototype.toString`
with a host object, the result will often be one of those values.

 Object.prototype.toString.call(alert);

results either "[object Function]" or "[object Object]". That behavior
is allowed in ES3, but why not in ES5? ES5 seems to defy what most (if
not all) implementations do there.

As far as ES5 is concerned, an implementation is perfectly allowed to have alert's [[Class]] be "Function", iff alert on that platform is a function, i.e., behaves as a function is obligated to behave. In fact, I think that is the most reasonable choice. If alert on a given implementation is instead a host object, then it has almost no rules governing its behavior. We don't wish it to be able to claim otherwise.

I have not yet seen any draft of the new WebIDL bindings for ES5. These may very well determine whether alert is a host object or a native function, as far as w3c specs are concerned. Either decision would be allowed by ES5.
 

Some host objects including `alert` are implemented as a native
ECMAScript objects (`alert instanceof Function`). In that case, the
[[Class]] property should be "Function".


(alert instanceof Function) is not a reliable test in either direction. A host object as well as a native non-function is perfectly free to inherit from Function.prototype and thus pass this test. And an actual function may be an instance of Function constructor from another frame and so fail the test. But yes, iff alert is indeed a native function, it's [[Class]] should be "Function".

 

However according to ES5 specs, any host object must not be withing
the set of values that are not allowable and so the assertion could be
made that if any object has a [[Class]] that is one of those values,
then the object is not a host object.

Yes, that is intentional.

 
An `isHostObject` method could
be written using a RegExp:

// DO NOT USE
var _toString = Object.prototype.toString,
   nativeClasses =
/Array|Boolean|Date|Error|Function|JSON|Math|Number|Object|RegExp|String/;

function isHostMethod(m) {
 return !nativeClasses.test(.call(m));
}

Surely you meant "_toString.call(m)"? And of the two names above, I think asHostObject is more appropriate, as it applies whether m is method-like or not.

Other than those typos, this code looks fine. Once one has determined that the platform is ES5, I think this code is perfectly good to use.


However, we know that won't hold true in many cases more than just `alert`.

Any implementation in which this doesn't hold is not a conformant ES5 implementation, and shouldn't claim otherwise.
 

Is the specification wrong here or what am I missing?

Garrett
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Garrett Smith
On 7/16/10, Mark S. Miller <[hidden email]> wrote:

> On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith
> <[hidden email]>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".

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

Because that allows `alert` to be any native ECMAScript object
(Function, Object, etc), while still letting it be defined as a host
object and not violating that spec. Iff, however, following my
proposed amendment, `alert` had [[Class]] "Object", and it was not a
native ES object (as in IE versions), then it would be a specification
violation.

> But it is also used from JS. Host objects are exempt from most of the
> specific behaviors specified for specific kinds of native objects. Were a
> host object to be able to allege to be a kind of native object without
> behaving as that kind of native object behaves, that would be bad.
>

This is not in the spec:
"without behaving as that kind of native object behaves"

While the specification does not preclude the possibility that a host
object may be implemented with native semantics, it nonetheless
defines a host object:

| 4.3.8
|  host object
|  object supplied by the host environment to complete the
|  execution environment of ECMAScript.
|
|  NOTE Any object that is not native is a host object.

And that means that `alert`, `window`, `document`, XMLHttpRequest, are
all host objects. Whether or not those objects are implemented as
native ECMAScript objects is another matter altogether.

It seems the the spec is wrong and that you have misinterpreted it. I
believe that instead it should be written:


>
>
>> Implementations don't agree; when calling `Object.prototype.toString`
>> with a host object, the result will often be one of those values.
>>
>>  Object.prototype.toString.call(alert);
>>
>> results either "[object Function]" or "[object Object]". That behavior
>> is allowed in ES3, but why not in ES5? ES5 seems to defy what most (if
>> not all) implementations do there.
>>
>
> As far as ES5 is concerned, an implementation is perfectly allowed to have
> alert's [[Class]] be "Function", iff alert on that platform is a function,
> i.e., behaves as a function is obligated to behave. In fact, I think that is
> the most reasonable choice. If alert on a given implementation is instead a
> host object, then it has almost no rules governing its behavior. We don't
> wish it to be able to claim otherwise.
>
> I have not yet seen any draft of the new WebIDL bindings for ES5. These may
> very well determine whether alert is a host object or a native function, as
> far as w3c specs are concerned. Either decision would be allowed by ES5.
>
>
>>
>> Some host objects including `alert` are implemented as a native
>> ECMAScript objects (`alert instanceof Function`). In that case, the
>> [[Class]] property should be "Function".
>>
>
>
> (alert instanceof Function) is not a reliable test in either direction.

No of course not.

A
> host object as well as a native non-function is perfectly free to inherit
> from Function.prototype and thus pass this test. And an actual function may
> be an instance of Function constructor from another frame and so fail the
> test. But yes, iff alert is indeed a native function, it's [[Class]] should
> be "Function".
>

Therein lies a contradiction: A host object here may be a function.
Yet because it is a host object, that same object's [[Class]] must not
be "Function", and yet again, since it is a function, and any function
must have [[Class]] "Function", then this object's [[Class]] must be
"Function".

>
>
>>
>> However according to ES5 specs, any host object must not be withing
>
> the set of values that are not allowable and so the assertion could be
>> made that if any object has a [[Class]] that is one of those values,
>> then the object is not a host object.
>
>
> Yes, that is intentional.

Then it will fail today, as

javascript: alert(({}).toString.call(alert))

- will result "[object Object]" or "[object Function]"

>>
>
> Surely you meant "_toString.call(m)"? And of the two names above, I think

Yes.

> asHostObject is more appropriate, as it applies whether m is method-like or
> not.
>
> Other than those typos, this code looks fine. Once one has determined that
> the platform is ES5, I think this code is perfectly good to use.
>

No, definitely not. It is not interoperable. Results vary depending on
the browser and host object in question. It does not reliably indicate
if an object is a host object, and in fact, that is too generous,
because in none of the implementations I tested will it indicate that
`alert` is a host object, which it is.

>
>> However, we know that won't hold true in many cases more than just
>> `alert`.
>>
>
> Any implementation in which this doesn't hold is not a conformant ES5
> implementation, and shouldn't claim otherwise.
>

All or most browser implementations will result either "Function" or
"Object" for [[Class]] property of `alert`, and so the above function
(typos fixed) would fail in every implementation.

It seems that the specification should change to reflect what
implementations do and what is wanted by other parts of the spec, as
suggested above.

Garrett
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Mark S. Miller-2
[+es5-discuss as a possible errata issue arises below]


On Sat, Jul 17, 2010 at 12:37 AM, Garrett Smith <[hidden email]> wrote:
On 7/16/10, Mark S. Miller <[hidden email]> wrote:
> On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith
> <[hidden email]>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.

 

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

 

Because that allows `alert` to be any native ECMAScript object
(Function, Object, etc), while still letting it be defined as a host
object and not violating that spec.


"that spec"? What specification demands that alert be a host object? I have not heard of any. This might be a consequence of the upcoming WebIDL-to-ES5 language bindings, but I have seen no draft and so have no idea. My own preference would be for these language bindings to result in alert being a native Function, but that's an argument for a different standards committee ;).

If an implementation's alert is a Function, then it is a native object and its [[Class]] must be "Function". It can still be an object provided by a host environment whose [[Call]] behavior is written in C++. This simply makes it a host provided native built-in object (4.3.7), not a host object.


 
Iff, however, following my
proposed amendment, `alert` had [[Class]] "Object", and it was not a
native ES object (as in IE versions), then it would be a specification
violation.

> But it is also used from JS. Host objects are exempt from most of the
> specific behaviors specified for specific kinds of native objects. Were a
> host object to be able to allege to be a kind of native object without
> behaving as that kind of native object behaves, that would be bad.
>

This is not in the spec:
"without behaving as that kind of native object behaves"

See 4.3.6.
 

While the specification does not preclude the possibility that a host
object may be implemented with native semantics, it nonetheless
defines a host object:

| 4.3.8
|  host object
|  object supplied by the host environment to complete the
|  execution environment of ECMAScript.
|
|  NOTE Any object that is not native is a host object.

And that means that `alert`, `window`, `document`, XMLHttpRequest, are
all host objects. Whether or not those objects are implemented as
native ECMAScript objects is another matter altogether.

This is the crux. The language there is indeed poorly phrased. But native objects are not host objects.

Indeed, it is so poorly phrased that perhaps we should add an errata to clean this up. Sigh. cc'ing es5-discuss.
 

It seems the the spec is wrong and that you have misinterpreted it. I
believe that instead it should be written:


Text missing?

 

>
>
>> Implementations don't agree; when calling `Object.prototype.toString`
>> with a host object, the result will often be one of those values.
>>
>>  Object.prototype.toString.call(alert);
>>
>> results either "[object Function]" or "[object Object]". That behavior
>> is allowed in ES3, but why not in ES5? ES5 seems to defy what most (if
>> not all) implementations do there.
>>
>
> As far as ES5 is concerned, an implementation is perfectly allowed to have
> alert's [[Class]] be "Function", iff alert on that platform is a function,
> i.e., behaves as a function is obligated to behave. In fact, I think that is
> the most reasonable choice. If alert on a given implementation is instead a
> host object, then it has almost no rules governing its behavior. We don't
> wish it to be able to claim otherwise.
>
> I have not yet seen any draft of the new WebIDL bindings for ES5. These may
> very well determine whether alert is a host object or a native function, as
> far as w3c specs are concerned. Either decision would be allowed by ES5.
>
>
>>
>> Some host objects including `alert` are implemented as a native
>> ECMAScript objects (`alert instanceof Function`). In that case, the
>> [[Class]] property should be "Function".
>>
>
>
> (alert instanceof Function) is not a reliable test in either direction.

No of course not.

A
> host object as well as a native non-function is perfectly free to inherit
> from Function.prototype and thus pass this test. And an actual function may
> be an instance of Function constructor from another frame and so fail the
> test. But yes, iff alert is indeed a native function, it's [[Class]] should
> be "Function".
>

Therein lies a contradiction: A host object here may be a function.

No it may not. A host object may be callable and it may inherit from Function.prototype, but it may not be a function.
 
Yet because it is a host object, that same object's [[Class]] must not
be "Function", and yet again, since it is a function, and any function
must have [[Class]] "Function", then this object's [[Class]] must be
"Function".

>
>
>>
>> However according to ES5 specs, any host object must not be withing
>
> the set of values that are not allowable and so the assertion could be
>> made that if any object has a [[Class]] that is one of those values,
>> then the object is not a host object.
>
>
> Yes, that is intentional.

Then it will fail today, as

javascript: alert(({}).toString.call(alert))

- will result "[object Object]" or "[object Function]"

1) No current implementations claim ES5 conformance.
2) On ES5 conformant implementations, alert may well be a function in which case the second result will remain correct.

 

>>
>
> Surely you meant "_toString.call(m)"? And of the two names above, I think

Yes.

> asHostObject is more appropriate, as it applies whether m is method-like or
> not.
>
> Other than those typos, this code looks fine. Once one has determined that
> the platform is ES5, I think this code is perfectly good to use.
>

No, definitely not. It is not interoperable. Results vary depending on
the browser and host object in question. It does not reliably indicate
if an object is a host object, and in fact, that is too generous,
because in none of the implementations I tested will it indicate that
`alert` is a host object, which it is.

I said "Once one has determined that the platform is ES5". None are yet available except Besen. Have you tested on an ES5 implementation?
 

>
>> However, we know that won't hold true in many cases more than just
>> `alert`.
>>
>
> Any implementation in which this doesn't hold is not a conformant ES5
> implementation, and shouldn't claim otherwise.
>

All or most browser implementations will result either "Function" or
"Object" for [[Class]] property of `alert`, and so the above function
(typos fixed) would fail in every implementation.

Again "Once one has determined that the platform is ES5". None of the current browser implementations are.
 

It seems that the specification should change to reflect what
implementations do and what is wanted by other parts of the spec, as
suggested above.

Garrett



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Garrett Smith
On 7/17/10, Mark S. Miller <[hidden email]> wrote:

> [+es5-discuss as a possible errata issue arises below]
>
>
> On Sat, Jul 17, 2010 at 12:37 AM, Garrett Smith
> <[hidden email]>wrote:
>
>> On 7/16/10, Mark S. Miller <[hidden email]> wrote:
>> > On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith
>> > <[hidden email]>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)

From the implementors point of view, what matters the ability derive
an inference from [[Class]]; if [[Class]] is x then [action]. However,
from a programmer's perspective, `Object.prototype.toString.call(x)`
cannot discriminate between objects originating in the host
environment (what is currently defined as "host object") and native
objects. Mostly they shouldn't care, but should follow the
specification approach to derive [[Class]] based inference, however
they can't follow that because that is not compatible with existing
implementations (notably IE versions and Opera (which copied IE)), and
making an "isStrict" supported global flag is not going to provide a
closely related inference about various types of host objects across a
wide range of implementations in the wild.

Internet Explorer 9 host objects seem to be absent of problems seen in
previous versions of IE but there are still host objects that are
callable, have [[Class]] "Object", and are not implemented with native
semantics. Two examples of such object are alert and addEventListener.

>
>
>>
>> Because that allows `alert` to be any native ECMAScript object
>> (Function, Object, etc), while still letting it be defined as a host
>> object and not violating that spec.
>
>
>
> "that spec"? What specification demands that alert be a host object? I have

I cited 4.3.8; the definition of host object.

> not heard of any. This might be a consequence of the upcoming WebIDL-to-ES5
> language bindings, but I have seen no draft and so have no idea. My own
> preference would be for these language bindings to result in alert being a
> native Function, but that's an argument for a different standards committee
> ;).
>
> If an implementation's alert is a Function, then it is a native object and
> its [[Class]] must be "Function". It can still be an object provided by a
> host environment whose [[Call]] behavior is written in C++. This simply
> makes it a host provided native built-in object (4.3.7), not a host object.
>

No, alert is not a defined by ECMAScript specification. It is
therefore host object, by definition of "host object" in ES5, s 4.3.8.

>
>
>
>> Iff, however, following my
>> proposed amendment, `alert` had [[Class]] "Object", and it was not a
>> native ES object (as in IE versions), then it would be a specification
>> violation.
>>
>> > But it is also used from JS. Host objects are exempt from most of the
>> > specific behaviors specified for specific kinds of native objects. Were
>> > a
>> > host object to be able to allege to be a kind of native object without
>> > behaving as that kind of native object behaves, that would be bad.
>> >
>>
>> This is not in the spec:
>> "without behaving as that kind of native object behaves"
>>
>
> See 4.3.6.
>

That is where native object is defined.

>
>>
>> While the specification does not preclude the possibility that a host
>> object may be implemented with native semantics, it nonetheless
>> defines a host object:
>>
>> | 4.3.8
>> |  host object
>> |  object supplied by the host environment to complete the
>> |  execution environment of ECMAScript.
>> |
>> |  NOTE Any object that is not native is a host object.
>>
>> And that means that `alert`, `window`, `document`, XMLHttpRequest, are
>> all host objects. Whether or not those objects are implemented as
>> native ECMAScript objects is another matter altogether.
>>
>
> This is the crux. The language there is indeed poorly phrased. But native
> objects are not host objects.
>

Where is that stated anywhere in the specification?

> Indeed, it is so poorly phrased that perhaps we should add an errata to
> clean this up. Sigh. cc'ing es5-discuss.
>
>
>>
>> It seems the the spec is wrong and that you have misinterpreted it. I
>> believe that instead it should be written:
>>
>>
> Text missing?

Yes, as I wrote before:

|  The value of the [[Class]] internal property of any non-native host
|  object must be any String value except one of..

The other possibility is that you have misinterpreted the definition
of host object to mean something along the lines of "any object that
is not a native object".

And going by that, referring to the example, `alert` could be a native
object and would then not be a host object.

[...]

>> > (alert instanceof Function) is not a reliable test in either direction.
>>
>> No of course not.
>>
>> A
>> > host object as well as a native non-function is perfectly free to
>> > inherit
>> > from Function.prototype and thus pass this test. And an actual function
>> may
>> > be an instance of Function constructor from another frame and so fail
>> > the
>> > test. But yes, iff alert is indeed a native function, it's [[Class]]
>> should
>> > be "Function".
>> >
>>
>> Therein lies a contradiction: A host object here may be a function.
>>
>
> No it may not. A host object may be callable and it may inherit from
> Function.prototype, but it may not be a function.
>

Once again, ES5 does not preclude the possibility that a host object
may be implemented with native semantics.

>
>> Yet because it is a host object, that same object's [[Class]] must not
>> be "Function", and yet again, since it is a function, and any function
>> must have [[Class]] "Function", then this object's [[Class]] must be
>> "Function".
>>
>> >
>> >
>> >>
>> >> However according to ES5 specs, any host object must not be withing
>> >
>> > the set of values that are not allowable and so the assertion could be
>> >> made that if any object has a [[Class]] that is one of those values,
>> >> then the object is not a host object.
>> >
>> >
>> > Yes, that is intentional.
>>
>> Then it will fail today, as
>>
>> javascript: alert(({}).toString.call(alert))
>>
>> - will result "[object Object]" or "[object Function]"
>>
>
> 1) No current implementations claim ES5 conformance.
> 2) On ES5 conformant implementations, alert may well be a function in which
> case the second result will remain correct.

The only way that could be anything other than a contradiction is if
you have redefined "host object" to be as I suggested above (I'll
repeat that one more time).

`alert` is a host object by definition of host object in s. 4.3.8. It
seems as if you have misinterpreted that definition as: "any object
that is not a native object". Is that how you read it?

That is a significantly different definition than either definition in
Eds 3 or 5.

Ed 3:

|   A host object is any object supplied by the host
|  environment to complete the execution environment of
|  ECMAScript. Any object that is not native is a host object.

Ed 5:
|  object supplied by the host environment to complete
|  the execution environment of ECMAScript.
|
|  NOTE Any object that is not native is a host object.

Perhaps this is a case of denying the antecedent?
1. if (not native) then host object.
2. alert is native,
therefore, alert is not host object. (false conclusion)

<http://en.wikipedia.org/wiki/Denying_the_antecedent>

If the definition of host object is correct then the clause that
mentions "[[Class]]" property must change as I initially suggested.
However, if what appears to be your definition of host object was also
what was intended by the editor, then that definition should be
rewritten instead.

If a host object is defined as being any object supplied by the host
environment that is not a native object, then the spec should state
so. If, however, a host object may be a native object -- and that is
how it is currently defined, then for any host object that is not a
native object, that object's [[Class]] property must not be in the set
of class values for native types.

Garrett
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Mark S. Miller-2
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 <[hidden email]> wrote:
On 7/17/10, Mark S. Miller <[hidden email]> wrote:
> [+es5-discuss as a possible errata issue arises below]
>
>
> On Sat, Jul 17, 2010 at 12:37 AM, Garrett Smith
> <[hidden email]>wrote:
>
>> On 7/16/10, Mark S. Miller <[hidden email]> wrote:
>> > On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith
>> > <[hidden email]>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)

From the implementors point of view, what matters the ability derive
an inference from [[Class]]; if [[Class]] is x then [action]. However,
from a programmer's perspective, `Object.prototype.toString.call(x)`
cannot discriminate between objects originating in the host
environment (what is currently defined as "host object") and native
objects. Mostly they shouldn't care, but should follow the
specification approach to derive [[Class]] based inference, however
they can't follow that because that is not compatible with existing
implementations (notably IE versions and Opera (which copied IE)), and
making an "isStrict" supported global flag is not going to provide a
closely related inference about various types of host objects across a
wide range of implementations in the wild.

Internet Explorer 9 host objects seem to be absent of problems seen in
previous versions of IE but there are still host objects that are
callable, have [[Class]] "Object", and are not implemented with native
semantics. Two examples of such object are alert and addEventListener.

>
>
>>
>> Because that allows `alert` to be any native ECMAScript object
>> (Function, Object, etc), while still letting it be defined as a host
>> object and not violating that spec.
>
>
>
> "that spec"? What specification demands that alert be a host object? I have

I cited 4.3.8; the definition of host object.

> not heard of any. This might be a consequence of the upcoming WebIDL-to-ES5
> language bindings, but I have seen no draft and so have no idea. My own
> preference would be for these language bindings to result in alert being a
> native Function, but that's an argument for a different standards committee
> ;).
>
> If an implementation's alert is a Function, then it is a native object and
> its [[Class]] must be "Function". It can still be an object provided by a
> host environment whose [[Call]] behavior is written in C++. This simply
> makes it a host provided native built-in object (4.3.7), not a host object.
>

No, alert is not a defined by ECMAScript specification. It is
therefore host object, by definition of "host object" in ES5, s 4.3.8.

>
>
>
>> Iff, however, following my
>> proposed amendment, `alert` had [[Class]] "Object", and it was not a
>> native ES object (as in IE versions), then it would be a specification
>> violation.
>>
>> > But it is also used from JS. Host objects are exempt from most of the
>> > specific behaviors specified for specific kinds of native objects. Were
>> > a
>> > host object to be able to allege to be a kind of native object without
>> > behaving as that kind of native object behaves, that would be bad.
>> >
>>
>> This is not in the spec:
>> "without behaving as that kind of native object behaves"
>>
>
> See 4.3.6.
>

That is where native object is defined.

>
>>
>> While the specification does not preclude the possibility that a host
>> object may be implemented with native semantics, it nonetheless
>> defines a host object:
>>
>> | 4.3.8
>> |  host object
>> |  object supplied by the host environment to complete the
>> |  execution environment of ECMAScript.
>> |
>> |  NOTE Any object that is not native is a host object.
>>
>> And that means that `alert`, `window`, `document`, XMLHttpRequest, are
>> all host objects. Whether or not those objects are implemented as
>> native ECMAScript objects is another matter altogether.
>>
>
> This is the crux. The language there is indeed poorly phrased. But native
> objects are not host objects.
>

Where is that stated anywhere in the specification?

> Indeed, it is so poorly phrased that perhaps we should add an errata to
> clean this up. Sigh. cc'ing es5-discuss.
>
>
>>
>> It seems the the spec is wrong and that you have misinterpreted it. I
>> believe that instead it should be written:
>>
>>
> Text missing?

Yes, as I wrote before:

|  The value of the [[Class]] internal property of any non-native host
|  object must be any String value except one of..

The other possibility is that you have misinterpreted the definition
of host object to mean something along the lines of "any object that
is not a native object".

And going by that, referring to the example, `alert` could be a native
object and would then not be a host object.

[...]

>> > (alert instanceof Function) is not a reliable test in either direction.
>>
>> No of course not.
>>
>> A
>> > host object as well as a native non-function is perfectly free to
>> > inherit
>> > from Function.prototype and thus pass this test. And an actual function
>> may
>> > be an instance of Function constructor from another frame and so fail
>> > the
>> > test. But yes, iff alert is indeed a native function, it's [[Class]]
>> should
>> > be "Function".
>> >
>>
>> Therein lies a contradiction: A host object here may be a function.
>>
>
> No it may not. A host object may be callable and it may inherit from
> Function.prototype, but it may not be a function.
>

Once again, ES5 does not preclude the possibility that a host object
may be implemented with native semantics.

>
>> Yet because it is a host object, that same object's [[Class]] must not
>> be "Function", and yet again, since it is a function, and any function
>> must have [[Class]] "Function", then this object's [[Class]] must be
>> "Function".
>>
>> >
>> >
>> >>
>> >> However according to ES5 specs, any host object must not be withing
>> >
>> > the set of values that are not allowable and so the assertion could be
>> >> made that if any object has a [[Class]] that is one of those values,
>> >> then the object is not a host object.
>> >
>> >
>> > Yes, that is intentional.
>>
>> Then it will fail today, as
>>
>> javascript: alert(({}).toString.call(alert))
>>
>> - will result "[object Object]" or "[object Function]"
>>
>
> 1) No current implementations claim ES5 conformance.
> 2) On ES5 conformant implementations, alert may well be a function in which
> case the second result will remain correct.

The only way that could be anything other than a contradiction is if
you have redefined "host object" to be as I suggested above (I'll
repeat that one more time).

`alert` is a host object by definition of host object in s. 4.3.8. It
seems as if you have misinterpreted that definition as: "any object
that is not a native object". Is that how you read it?

That is a significantly different definition than either definition in
Eds 3 or 5.

Ed 3:

|   A host object is any object supplied by the host
|  environment to complete the execution environment of
|  ECMAScript. Any object that is not native is a host object.

Ed 5:
|  object supplied by the host environment to complete
|  the execution environment of ECMAScript.
|
|  NOTE Any object that is not native is a host object.

Perhaps this is a case of denying the antecedent?
1. if (not native) then host object.
2. alert is native,
therefore, alert is not host object. (false conclusion)

<http://en.wikipedia.org/wiki/Denying_the_antecedent>

If the definition of host object is correct then the clause that
mentions "[[Class]]" property must change as I initially suggested.
However, if what appears to be your definition of host object was also
what was intended by the editor, then that definition should be
rewritten instead.

If a host object is defined as being any object supplied by the host
environment that is not a native object, then the spec should state
so. If, however, a host object may be a native object -- and that is
how it is currently defined, then for any host object that is not a
native object, that object's [[Class]] property must not be in the set
of class values for native types.

Garrett



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: [[Class]] Property of Host Object

Allen Wirfs-Brock-2

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: [hidden email] [mailto:[hidden email]] On Behalf Of Mark S. Miller
Sent: Saturday, July 17, 2010 12:54 PM
To: Garrett Smith
Cc: [hidden email]; 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 <[hidden email]> wrote:

On 7/17/10, Mark S. Miller <[hidden email]> wrote:
> [+es5-discuss as a possible errata issue arises below]
>
>
> On Sat, Jul 17, 2010 at 12:37 AM, Garrett Smith
> <[hidden email]>wrote:
>
>> On 7/16/10, Mark S. Miller <[hidden email]> wrote:
>> > On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith
>> > <[hidden email]>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)

From the implementors point of view, what matters the ability derive
an inference from [[Class]]; if [[Class]] is x then [action]. However,
from a programmer's perspective, `Object.prototype.toString.call(x)`
cannot discriminate between objects originating in the host
environment (what is currently defined as "host object") and native
objects. Mostly they shouldn't care, but should follow the
specification approach to derive [[Class]] based inference, however
they can't follow that because that is not compatible with existing
implementations (notably IE versions and Opera (which copied IE)), and
making an "isStrict" supported global flag is not going to provide a
closely related inference about various types of host objects across a
wide range of implementations in the wild.

Internet Explorer 9 host objects seem to be absent of problems seen in
previous versions of IE but there are still host objects that are
callable, have [[Class]] "Object", and are not implemented with native
semantics. Two examples of such object are alert and addEventListener.


>
>
>>
>> Because that allows `alert` to be any native ECMAScript object
>> (Function, Object, etc), while still letting it be defined as a host
>> object and not violating that spec.
>
>
>
> "that spec"? What specification demands that alert be a host object? I have

I cited 4.3.8; the definition of host object.


> not heard of any. This might be a consequence of the upcoming WebIDL-to-ES5
> language bindings, but I have seen no draft and so have no idea. My own
> preference would be for these language bindings to result in alert being a
> native Function, but that's an argument for a different standards committee
> ;).
>
> If an implementation's alert is a Function, then it is a native object and
> its [[Class]] must be "Function". It can still be an object provided by a
> host environment whose [[Call]] behavior is written in C++. This simply
> makes it a host provided native built-in object (4.3.7), not a host object.
>

No, alert is not a defined by ECMAScript specification. It is
therefore host object, by definition of "host object" in ES5, s 4.3.8.


>
>
>
>> Iff, however, following my
>> proposed amendment, `alert` had [[Class]] "Object", and it was not a
>> native ES object (as in IE versions), then it would be a specification
>> violation.
>>
>> > But it is also used from JS. Host objects are exempt from most of the
>> > specific behaviors specified for specific kinds of native objects. Were
>> > a
>> > host object to be able to allege to be a kind of native object without
>> > behaving as that kind of native object behaves, that would be bad.
>> >
>>
>> This is not in the spec:
>> "without behaving as that kind of native object behaves"
>>
>
> See 4.3.6.
>

That is where native object is defined.


>
>>
>> While the specification does not preclude the possibility that a host
>> object may be implemented with native semantics, it nonetheless
>> defines a host object:
>>
>> | 4.3.8
>> |  host object
>> |  object supplied by the host environment to complete the
>> |  execution environment of ECMAScript.
>> |
>> |  NOTE Any object that is not native is a host object.
>>
>> And that means that `alert`, `window`, `document`, XMLHttpRequest, are
>> all host objects. Whether or not those objects are implemented as
>> native ECMAScript objects is another matter altogether.
>>
>
> This is the crux. The language there is indeed poorly phrased. But native
> objects are not host objects.
>

Where is that stated anywhere in the specification?


> Indeed, it is so poorly phrased that perhaps we should add an errata to
> clean this up. Sigh. cc'ing es5-discuss.
>
>
>>
>> It seems the the spec is wrong and that you have misinterpreted it. I
>> believe that instead it should be written:
>>
>>
> Text missing?

Yes, as I wrote before:


|  The value of the [[Class]] internal property of any non-native host
|  object must be any String value except one of..

The other possibility is that you have misinterpreted the definition
of host object to mean something along the lines of "any object that
is not a native object".

And going by that, referring to the example, `alert` could be a native
object and would then not be a host object.

[...]


>> > (alert instanceof Function) is not a reliable test in either direction.
>>
>> No of course not.
>>
>> A
>> > host object as well as a native non-function is perfectly free to
>> > inherit
>> > from Function.prototype and thus pass this test. And an actual function
>> may
>> > be an instance of Function constructor from another frame and so fail
>> > the
>> > test. But yes, iff alert is indeed a native function, it's [[Class]]
>> should
>> > be "Function".
>> >
>>
>> Therein lies a contradiction: A host object here may be a function.
>>
>
> No it may not. A host object may be callable and it may inherit from
> Function.prototype, but it may not be a function.
>

Once again, ES5 does not preclude the possibility that a host object
may be implemented with native semantics.


>
>> Yet because it is a host object, that same object's [[Class]] must not
>> be "Function", and yet again, since it is a function, and any function
>> must have [[Class]] "Function", then this object's [[Class]] must be
>> "Function".
>>
>> >
>> >
>> >>
>> >> However according to ES5 specs, any host object must not be withing
>> >
>> > the set of values that are not allowable and so the assertion could be
>> >> made that if any object has a [[Class]] that is one of those values,
>> >> then the object is not a host object.
>> >
>> >
>> > Yes, that is intentional.
>>
>> Then it will fail today, as
>>
>> javascript: alert(({}).toString.call(alert))
>>
>> - will result "[object Object]" or "[object Function]"
>>
>
> 1) No current implementations claim ES5 conformance.
> 2) On ES5 conformant implementations, alert may well be a function in which
> case the second result will remain correct.

The only way that could be anything other than a contradiction is if
you have redefined "host object" to be as I suggested above (I'll
repeat that one more time).

`alert` is a host object by definition of host object in s. 4.3.8. It
seems as if you have misinterpreted that definition as: "any object
that is not a native object". Is that how you read it?

That is a significantly different definition than either definition in
Eds 3 or 5.

Ed 3:

|   A host object is any object supplied by the host

|  environment to complete the execution environment of

|  ECMAScript. Any object that is not native is a host object.

Ed 5:

|  object supplied by the host environment to complete
|  the execution environment of ECMAScript.
|
|  NOTE Any object that is not native is a host object.

Perhaps this is a case of denying the antecedent?
1. if (not native) then host object.
2. alert is native,
therefore, alert is not host object. (false conclusion)

<http://en.wikipedia.org/wiki/Denying_the_antecedent>

If the definition of host object is correct then the clause that
mentions "[[Class]]" property must change as I initially suggested.
However, if what appears to be your definition of host object was also
what was intended by the editor, then that definition should be
rewritten instead.

If a host object is defined as being any object supplied by the host
environment that is not a native object, then the spec should state
so. If, however, a host object may be a native object -- and that is
how it is currently defined, then for any host object that is not a
native object, that object's [[Class]] property must not be in the set
of class values for native types.

Garrett




--
    Cheers,
    --MarkM


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Mark S. Miller-2
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Mark S. Miller
Sent: Saturday, July 17, 2010 12:54 PM
To: Garrett Smith
Cc: [hidden email]; 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 <[hidden email]> wrote:

On 7/17/10, Mark S. Miller <[hidden email]> wrote:
> [+es5-discuss as a possible errata issue arises below]
>
>
> On Sat, Jul 17, 2010 at 12:37 AM, Garrett Smith
> <[hidden email]>wrote:
>
>> On 7/16/10, Mark S. Miller <[hidden email]> wrote:
>> > On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith
>> > <[hidden email]>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)

From the implementors point of view, what matters the ability derive
an inference from [[Class]]; if [[Class]] is x then [action]. However,
from a programmer's perspective, `Object.prototype.toString.call(x)`
cannot discriminate between objects originating in the host
environment (what is currently defined as "host object") and native
objects. Mostly they shouldn't care, but should follow the
specification approach to derive [[Class]] based inference, however
they can't follow that because that is not compatible with existing
implementations (notably IE versions and Opera (which copied IE)), and
making an "isStrict" supported global flag is not going to provide a
closely related inference about various types of host objects across a
wide range of implementations in the wild.

Internet Explorer 9 host objects seem to be absent of problems seen in
previous versions of IE but there are still host objects that are
callable, have [[Class]] "Object", and are not implemented with native
semantics. Two examples of such object are alert and addEventListener.


>
>
>>
>> Because that allows `alert` to be any native ECMAScript object
>> (Function, Object, etc), while still letting it be defined as a host
>> object and not violating that spec.
>
>
>
> "that spec"? What specification demands that alert be a host object? I have

I cited 4.3.8; the definition of host object.


> not heard of any. This might be a consequence of the upcoming WebIDL-to-ES5
> language bindings, but I have seen no draft and so have no idea. My own
> preference would be for these language bindings to result in alert being a
> native Function, but that's an argument for a different standards committee
> ;).
>
> If an implementation's alert is a Function, then it is a native object and
> its [[Class]] must be "Function". It can still be an object provided by a
> host environment whose [[Call]] behavior is written in C++. This simply
> makes it a host provided native built-in object (4.3.7), not a host object.
>

No, alert is not a defined by ECMAScript specification. It is
therefore host object, by definition of "host object" in ES5, s 4.3.8.


>
>
>
>> Iff, however, following my
>> proposed amendment, `alert` had [[Class]] "Object", and it was not a
>> native ES object (as in IE versions), then it would be a specification
>> violation.
>>
>> > But it is also used from JS. Host objects are exempt from most of the
>> > specific behaviors specified for specific kinds of native objects. Were
>> > a
>> > host object to be able to allege to be a kind of native object without
>> > behaving as that kind of native object behaves, that would be bad.
>> >
>>
>> This is not in the spec:
>> "without behaving as that kind of native object behaves"
>>
>
> See 4.3.6.
>

That is where native object is defined.


>
>>
>> While the specification does not preclude the possibility that a host
>> object may be implemented with native semantics, it nonetheless
>> defines a host object:
>>
>> | 4.3.8
>> |  host object
>> |  object supplied by the host environment to complete the
>> |  execution environment of ECMAScript.
>> |
>> |  NOTE Any object that is not native is a host object.
>>
>> And that means that `alert`, `window`, `document`, XMLHttpRequest, are
>> all host objects. Whether or not those objects are implemented as
>> native ECMAScript objects is another matter altogether.
>>
>
> This is the crux. The language there is indeed poorly phrased. But native
> objects are not host objects.
>

Where is that stated anywhere in the specification?


> Indeed, it is so poorly phrased that perhaps we should add an errata to
> clean this up. Sigh. cc'ing es5-discuss.
>
>
>>
>> It seems the the spec is wrong and that you have misinterpreted it. I
>> believe that instead it should be written:
>>
>>
> Text missing?

Yes, as I wrote before:


|  The value of the [[Class]] internal property of any non-native host
|  object must be any String value except one of..

The other possibility is that you have misinterpreted the definition
of host object to mean something along the lines of "any object that
is not a native object".

And going by that, referring to the example, `alert` could be a native
object and would then not be a host object.

[...]


>> > (alert instanceof Function) is not a reliable test in either direction.
>>
>> No of course not.
>>
>> A
>> > host object as well as a native non-function is perfectly free to
>> > inherit
>> > from Function.prototype and thus pass this test. And an actual function
>> may
>> > be an instance of Function constructor from another frame and so fail
>> > the
>> > test. But yes, iff alert is indeed a native function, it's [[Class]]
>> should
>> > be "Function".
>> >
>>
>> Therein lies a contradiction: A host object here may be a function.
>>
>
> No it may not. A host object may be callable and it may inherit from
> Function.prototype, but it may not be a function.
>

Once again, ES5 does not preclude the possibility that a host object
may be implemented with native semantics.


>
>> Yet because it is a host object, that same object's [[Class]] must not
>> be "Function", and yet again, since it is a function, and any function
>> must have [[Class]] "Function", then this object's [[Class]] must be
>> "Function".
>>
>> >
>> >
>> >>
>> >> However according to ES5 specs, any host object must not be withing
>> >
>> > the set of values that are not allowable and so the assertion could be
>> >> made that if any object has a [[Class]] that is one of those values,
>> >> then the object is not a host object.
>> >
>> >
>> > Yes, that is intentional.
>>
>> Then it will fail today, as
>>
>> javascript: alert(({}).toString.call(alert))
>>
>> - will result "[object Object]" or "[object Function]"
>>
>
> 1) No current implementations claim ES5 conformance.
> 2) On ES5 conformant implementations, alert may well be a function in which
> case the second result will remain correct.

The only way that could be anything other than a contradiction is if
you have redefined "host object" to be as I suggested above (I'll
repeat that one more time).

`alert` is a host object by definition of host object in s. 4.3.8. It
seems as if you have misinterpreted that definition as: "any object
that is not a native object". Is that how you read it?

That is a significantly different definition than either definition in
Eds 3 or 5.

Ed 3:

|   A host object is any object supplied by the host

|  environment to complete the execution environment of

|  ECMAScript. Any object that is not native is a host object.

Ed 5:

|  object supplied by the host environment to complete
|  the execution environment of ECMAScript.
|
|  NOTE Any object that is not native is a host object.

Perhaps this is a case of denying the antecedent?
1. if (not native) then host object.
2. alert is native,
therefore, alert is not host object. (false conclusion)

<http://en.wikipedia.org/wiki/Denying_the_antecedent>

If the definition of host object is correct then the clause that
mentions "[[Class]]" property must change as I initially suggested.
However, if what appears to be your definition of host object was also
what was intended by the editor, then that definition should be
rewritten instead.

If a host object is defined as being any object supplied by the host
environment that is not a native object, then the spec should state
so. If, however, a host object may be a native object -- and that is
how it is currently defined, then for any host object that is not a
native object, that object's [[Class]] property must not be in the set
of class values for native types.

Garrett




--
    Cheers,
    --MarkM




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: [[Class]] Property of Host Object

Allen Wirfs-Brock-2

>> 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:[hidden email]]
Sent: Sunday, July 18, 2010 9:52 AM
To: Allen Wirfs-Brock
Cc: Garrett Smith; [hidden email]; 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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Mark S. Miller
Sent: Saturday, July 17, 2010 12:54 PM
To: Garrett Smith
Cc: [hidden email]; 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 <[hidden email]> wrote:

On 7/17/10, Mark S. Miller <[hidden email]> wrote:
> [+es5-discuss as a possible errata issue arises below]
>
>
> On Sat, Jul 17, 2010 at 12:37 AM, Garrett Smith
> <[hidden email]>wrote:
>
>> On 7/16/10, Mark S. Miller <[hidden email]> wrote:
>> > On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith
>> > <[hidden email]>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)

From the implementors point of view, what matters the ability derive
an inference from [[Class]]; if [[Class]] is x then [action]. However,
from a programmer's perspective, `Object.prototype.toString.call(x)`
cannot discriminate between objects originating in the host
environment (what is currently defined as "host object") and native
objects. Mostly they shouldn't care, but should follow the
specification approach to derive [[Class]] based inference, however
they can't follow that because that is not compatible with existing
implementations (notably IE versions and Opera (which copied IE)), and
making an "isStrict" supported global flag is not going to provide a
closely related inference about various types of host objects across a
wide range of implementations in the wild.

Internet Explorer 9 host objects seem to be absent of problems seen in
previous versions of IE but there are still host objects that are
callable, have [[Class]] "Object", and are not implemented with native
semantics. Two examples of such object are alert and addEventListener.


>
>
>>
>> Because that allows `alert` to be any native ECMAScript object
>> (Function, Object, etc), while still letting it be defined as a host
>> object and not violating that spec.
>
>
>
> "that spec"? What specification demands that alert be a host object? I have

I cited 4.3.8; the definition of host object.


> not heard of any. This might be a consequence of the upcoming WebIDL-to-ES5
> language bindings, but I have seen no draft and so have no idea. My own
> preference would be for these language bindings to result in alert being a
> native Function, but that's an argument for a different standards committee
> ;).
>
> If an implementation's alert is a Function, then it is a native object and
> its [[Class]] must be "Function". It can still be an object provided by a
> host environment whose [[Call]] behavior is written in C++. This simply
> makes it a host provided native built-in object (4.3.7), not a host object.
>

No, alert is not a defined by ECMAScript specification. It is
therefore host object, by definition of "host object" in ES5, s 4.3.8.


>
>
>
>> Iff, however, following my
>> proposed amendment, `alert` had [[Class]] "Object", and it was not a
>> native ES object (as in IE versions), then it would be a specification
>> violation.
>>
>> > But it is also used from JS. Host objects are exempt from most of the
>> > specific behaviors specified for specific kinds of native objects. Were
>> > a
>> > host object to be able to allege to be a kind of native object without
>> > behaving as that kind of native object behaves, that would be bad.
>> >
>>
>> This is not in the spec:
>> "without behaving as that kind of native object behaves"
>>
>
> See 4.3.6.
>

That is where native object is defined.


>
>>
>> While the specification does not preclude the possibility that a host
>> object may be implemented with native semantics, it nonetheless
>> defines a host object:
>>
>> | 4.3.8
>> |  host object
>> |  object supplied by the host environment to complete the
>> |  execution environment of ECMAScript.
>> |
>> |  NOTE Any object that is not native is a host object.
>>
>> And that means that `alert`, `window`, `document`, XMLHttpRequest, are
>> all host objects. Whether or not those objects are implemented as
>> native ECMAScript objects is another matter altogether.
>>
>
> This is the crux. The language there is indeed poorly phrased. But native
> objects are not host objects.
>

Where is that stated anywhere in the specification?


> Indeed, it is so poorly phrased that perhaps we should add an errata to
> clean this up. Sigh. cc'ing es5-discuss.
>
>
>>
>> It seems the the spec is wrong and that you have misinterpreted it. I
>> believe that instead it should be written:
>>
>>
> Text missing?

Yes, as I wrote before:


|  The value of the [[Class]] internal property of any non-native host
|  object must be any String value except one of..

The other possibility is that you have misinterpreted the definition
of host object to mean something along the lines of "any object that
is not a native object".

And going by that, referring to the example, `alert` could be a native
object and would then not be a host object.

[...]


>> > (alert instanceof Function) is not a reliable test in either direction.
>>
>> No of course not.
>>
>> A
>> > host object as well as a native non-function is perfectly free to
>> > inherit
>> > from Function.prototype and thus pass this test. And an actual function
>> may
>> > be an instance of Function constructor from another frame and so fail
>> > the
>> > test. But yes, iff alert is indeed a native function, it's [[Class]]
>> should
>> > be "Function".
>> >
>>
>> Therein lies a contradiction: A host object here may be a function.
>>
>
> No it may not. A host object may be callable and it may inherit from
> Function.prototype, but it may not be a function.
>

Once again, ES5 does not preclude the possibility that a host object
may be implemented with native semantics.


>
>> Yet because it is a host object, that same object's [[Class]] must not
>> be "Function", and yet again, since it is a function, and any function
>> must have [[Class]] "Function", then this object's [[Class]] must be
>> "Function".
>>
>> >
>> >
>> >>
>> >> However according to ES5 specs, any host object must not be withing
>> >
>> > the set of values that are not allowable and so the assertion could be
>> >> made that if any object has a [[Class]] that is one of those values,
>> >> then the object is not a host object.
>> >
>> >
>> > Yes, that is intentional.
>>
>> Then it will fail today, as
>>
>> javascript: alert(({}).toString.call(alert))
>>
>> - will result "[object Object]" or "[object Function]"
>>
>
> 1) No current implementations claim ES5 conformance.
> 2) On ES5 conformant implementations, alert may well be a function in which
> case the second result will remain correct.

The only way that could be anything other than a contradiction is if
you have redefined "host object" to be as I suggested above (I'll
repeat that one more time).

`alert` is a host object by definition of host object in s. 4.3.8. It
seems as if you have misinterpreted that definition as: "any object
that is not a native object". Is that how you read it?

That is a significantly different definition than either definition in
Eds 3 or 5.

Ed 3:

|   A host object is any object supplied by the host

|  environment to complete the execution environment of

|  ECMAScript. Any object that is not native is a host object.

Ed 5:

|  object supplied by the host environment to complete
|  the execution environment of ECMAScript.
|
|  NOTE Any object that is not native is a host object.

Perhaps this is a case of denying the antecedent?
1. if (not native) then host object.
2. alert is native,
therefore, alert is not host object. (false conclusion)

<http://en.wikipedia.org/wiki/Denying_the_antecedent>

If the definition of host object is correct then the clause that
mentions "[[Class]]" property must change as I initially suggested.
However, if what appears to be your definition of host object was also
what was intended by the editor, then that definition should be
rewritten instead.

If a host object is defined as being any object supplied by the host
environment that is not a native object, then the spec should state
so. If, however, a host object may be a native object -- and that is
how it is currently defined, then for any host object that is not a
native object, that object's [[Class]] property must not be in the set
of class values for native types.

Garrett




--
    Cheers,
    --MarkM




--
    Cheers,
    --MarkM


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Garrett Smith
On 7/18/10, Allen Wirfs-Brock <[hidden email]> wrote:
>>> 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


I hope the same can be said for the bug related to catch clauses and
scope in IE9.

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

What is the basis for making assertions of what the [[Class]] for any
host object should be?

[...]

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

While that is true for the purposes of the specification, it is not
necessarily true for script authors. For any script wanting to define
`isHostObject`, that script is going to be in a predicament.

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

Again, if the specification definition of host object is correct --
and you have confirmed that it is -- then there are two types of host
objects, native, and non-native. And in that case, the clause that
mentions "[[Class]]" property must change as I initially suggested.

[snip remainder]

Garrett
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: [[Class]] Property of Host Object

Allen Wirfs-Brock-2
> -----Original Message-----
> From: Garrett Smith [mailto:[hidden email]]
>
> I hope the same can be said for the bug related to catch clauses and scope in
> IE9.
>
Bugs are for reporting and fixing...it's been reported but if you're ever unsure it never hurts to report it via http://connect.microsoft.com/ie 

>
> While that is true for the purposes of the specification, it is not necessarily true
> for script authors. For any script wanting to define `isHostObject`, that script is
> going to be in a predicament.
>

isHostObject sounds inherently implementation dependent to me.  I don't see how you could possibly write such a thing in an implementation independent manner, given the current specification.  I also don't know why you would want to.  What's the use case?

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Mark S. Miller-2
In reply to this post by Allen Wirfs-Brock-2
On Sun, Jul 18, 2010 at 5:58 PM, Allen Wirfs-Brock <[hidden email]> wrote:

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


Is the following one of those cases:

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

If so, then I think we may simply have a term rotation. Everytime I say "host object", and AFAICT every time the spec says "host object" other than the definition (4.3.8), both I and it mean what you refer to above as a "non-native host object". Also, by your clarification above, a "native host object" seems indistinguishable from any other "native object", so I'm not sure what purpose the distinction has.

In any case, we clearly have a disagreement about our memory of what we took these terms to mean. Anyone else who was there, care to weigh in?

 

--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Garrett Smith
In reply to this post by Allen Wirfs-Brock-2
On 7/18/10, Allen Wirfs-Brock <[hidden email]> wrote:

>> -----Original Message-----
>> From: Garrett Smith [mailto:[hidden email]]
>>
>> I hope the same can be said for the bug related to catch clauses and scope
>> in
>> IE9.
>>
> Bugs are for reporting and fixing...it's been reported but if you're ever
> unsure it never hurts to report it via http://connect.microsoft.com/ie
>

My answer to each an every one of those survey questions (I don't
really have time, so feel  free to complete it for me, Allen) is
"Please fix your website".


>>
>> While that is true for the purposes of the specification, it is not
>> necessarily true
>> for script authors. For any script wanting to define `isHostObject`, that
>> script is
>> going to be in a predicament.
>>
>
> isHostObject sounds inherently implementation dependent to me.  I don't see
> how you could possibly write such a thing in an implementation independent
> manner, given the current specification.  I also don't know why you would
> want to.  What's the use case?
>

Did you miss the part where I wrote:

 “However, from a programmer's perspective, `Object.prototype.toString.call(x)`
cannot discriminate between objects originating in the host
environment (what is currently defined as "host object") and native
objects. Mostly they shouldn't care, but should follow the
specification approach to derive [[Class]] based inference, however
they can't follow that because that is not compatible with existing
implementations (notably IE versions and Opera (which copied IE)), and
making an "isStrict"”

?

Garrett
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: [[Class]] Property of Host Object

Allen Wirfs-Brock-2
In reply to this post by Mark S. Miller-2
> -----Original Message-----
> From: Mark S. Miller [mailto:[hidden email]]
...
> Is the following one of those cases:
>
> > 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"
>
 
Yes. As you said in an earlier message, the intent was that the host should environment should not violate specification of the nominal "types" used by the specification.  But certainly, a host environment  could produce such values and even management them differently as long as it doesn't violate any the semantics for that "type" that appear in the ES5 spec.

> If so, then I think we may simply have a term rotation. Everytime I say "host
> object", and AFAICT every time the spec says "host object" other than the
> definition (4.3.8), both I and it mean what you refer to above as a "non-native
> host object". Also, by your clarification above, a "native host object" seems
> indistinguishable from any other "native object", so I'm not sure what purpose
> the distinction has.
>
Yes, I agree.  I think the main "bug"  in this regard in the spec. in that the definition in 4.3.8 does not clarify this distinction. But note that 4.3.6 is quite clear that a native object is /any/ object whose semantics are fully defined by the ES5 specification and the note to 4.3.8 says that any object that is not native (ie whose semantics are not fully defined by the ES5 specification) is a host object.  The only host objects that the spec. needs to explicitly talk about are host objects that are not native objects.

> In any case, we clearly have a disagreement about our memory of what we took
> these terms to mean. Anyone else who was there, care to weigh in?
>
Do we??  What do you think "host object" means?


Allen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Mark S. Miller-2


On Mon, Jul 19, 2010 at 1:49 PM, Allen Wirfs-Brock <[hidden email]> wrote:
> -----Original Message-----
> From: Mark S. Miller [mailto:[hidden email]]
...
> Is the following one of those cases:
>
> > 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"
>

Yes. As you said in an earlier message, the intent was that the host should environment should not violate specification of the nominal "types" used by the specification.  But certainly, a host environment  could produce such values and even management them differently as long as it doesn't violate any the semantics for that "type" that appear in the ES5 spec.

> If so, then I think we may simply have a term rotation. Everytime I say "host
> object", and AFAICT every time the spec says "host object" other than the
> definition (4.3.8), both I and it mean what you refer to above as a "non-native
> host object". Also, by your clarification above, a "native host object" seems
> indistinguishable from any other "native object", so I'm not sure what purpose
> the distinction has.
>
Yes, I agree.  I think the main "bug"  in this regard in the spec. in that the definition in 4.3.8 does not clarify this distinction. But note that 4.3.6 is quite clear that a native object is /any/ object whose semantics are fully defined by the ES5 specification and the note to 4.3.8 says that any object that is not native (ie whose semantics are not fully defined by the ES5 specification) is a host object.  The only host objects that the spec. needs to explicitly talk about are host objects that are not native objects.

> In any case, we clearly have a disagreement about our memory of what we took
> these terms to mean. Anyone else who was there, care to weigh in?
>
Do we??  What do you think "host object" means?

Objects that are not native objects. I.e., the categories are disjoint and Garrett's isHostObject method is correct.

 


Allen
_______________________________________________
es5-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es5-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: [[Class]] Property of Host Object

Allen Wirfs-Brock-2
> -----Original Message-----
> From: Mark S. Miller [mailto:[hidden email]]
> Sent: Monday, July 19, 2010 2:02 PM
> >
>> Do we??  What do you think "host object" means?
>
> Objects that are not native objects. I.e., the categories are disjoint and Garrett's
> isHostObject method is correct.
>

Ok, I think we generally agree.  "host object" as used in the ES5 spec. in essentially all cases means  "not native object".  Garrett's isHostObject test would arguably almost be valid if used within a perfectly conforming and unextended ES5 implementation.  However, a conforming implementation is allowed to "provide additional types, values, objects,..." and such extensions might include the use of new [[Class]] values.  For example, the JSON object is semantically a perfectly normal native object but has a distinct [[Class]] value.  If an implementation included a different but similar extension isHostObject would classify it as a "host object".  Whether or not you are happy with that result probably depends upon your isHostObject use case.

The starting point of this discussion seems to be the desire to find a reliable way to discriminate  "host objects".  ES5 wasn't intentionally trying to provide such a mechanism and I don't believe that it accidently did so.

Allen  
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Mark S. Miller-2
On Mon, Jul 19, 2010 at 2:35 PM, Allen Wirfs-Brock <[hidden email]> wrote:
> -----Original Message-----
> From: Mark S. Miller [mailto:[hidden email]]
> Sent: Monday, July 19, 2010 2:02 PM
> >
>> Do we??  What do you think "host object" means?
>
> Objects that are not native objects. I.e., the categories are disjoint and Garrett's
> isHostObject method is correct.
>

Ok, I think we generally agree.  "host object" as used in the ES5 spec. in essentially all cases means  "not native object".  Garrett's isHostObject test would arguably almost be valid if used within a perfectly conforming and unextended ES5 implementation.  However, a conforming implementation is allowed to "provide additional types, values, objects,..." and such extensions might include the use of new [[Class]] values.  For example, the JSON object is semantically a perfectly normal native object but has a distinct [[Class]] value.  If an implementation included a different but similar extension isHostObject would classify it as a "host object".  Whether or not you are happy with that result probably depends upon your isHostObject use case.

I agree. FWIW, I am happy with that result. By the definition of ES5 "native object", such an object is not an ES5 native object, since it has a [[Class]] value not defined by the ES5 spec. By the note on the host object definition, it is therefore (to ES5) a host object.

Perhaps Garrett's function should be renamed isES5HostObject for clarity. With that new name, I would feel comfortable using and recommending use of that function.
 

The starting point of this discussion seems to be the desire to find a reliable way to discriminate  "host objects".  ES5 wasn't intentionally trying to provide such a mechanism and I don't believe that it accidently did so.

I agree that we did not intend to provide such a discrimination mechanism. But I do think we accidentally did so.

 

Allen



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

David Flanagan
Allen,

The host vs. native distinction has long bothered me as well.  Thanks
for a particularly lucid explanation.  In the next edition of the spec,
perhaps you could go further and eliminate the use of the word "host"
altogether, leaving you with only native objects and non-native objects.
  Then you don't have to say that host objects can be native, or non-native.

Garrett,

You could drop the confusing word "host", too.  If you invert the
boolean sense of your function then you can call it isNativeObject() or
isNativeValue() or just isNative().

I submitted similar comments to Allen while the spec was in its public
review phase.  I didn't feel strongly about getting it fixed, however,
because the ambiguous definitions in question are in a non-normative
portion of the spec.  (All of section 4, including the definitions are
non-normative.)

And tangentially related to the original question about the nature of
alert, and tangentally related to the notion of accidentally provided
discrimination mechanisms, here is how to determine whether an ES5
object (native or non-native) is callable.  It relies on the fact that
forEach() tests for callability before checking for an empty array.

Object.isCallable = function(o) {
     // Array.prototype.forEach throws TypeError for non-callable args
     try {
         [].forEach(o);  // o will never be invoked since array is empty
         return true;
     } catch (x) {
         if (x instanceof TypeError) return false;
         else throw x;
     }
};

Of course I don't have an ES5 implementation with callable objects that
are not functions to test it out on.

        David

Mark S. Miller wrote:

> On Mon, Jul 19, 2010 at 2:35 PM, Allen Wirfs-Brock
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>      > -----Original Message-----
>      > From: Mark S. Miller [mailto:[hidden email]
>     <mailto:[hidden email]>]
>      > Sent: Monday, July 19, 2010 2:02 PM
>      > >
>      >> Do we??  What do you think "host object" means?
>      >
>      > Objects that are not native objects. I.e., the categories are
>     disjoint and Garrett's
>      > isHostObject method is correct.
>      >
>
>     Ok, I think we generally agree.  "host object" as used in the ES5
>     spec. in essentially all cases means  "not native object".
>      Garrett's isHostObject test would arguably almost be valid if used
>     within a perfectly conforming and unextended ES5 implementation.
>      However, a conforming implementation is allowed to "provide
>     additional types, values, objects,..." and such extensions might
>     include the use of new [[Class]] values.  For example, the JSON
>     object is semantically a perfectly normal native object but has a
>     distinct [[Class]] value.  If an implementation included a different
>     but similar extension isHostObject would classify it as a "host
>     object".  Whether or not you are happy with that result probably
>     depends upon your isHostObject use case.
>
>
> I agree. FWIW, I am happy with that result. By the definition of ES5
> "native object", such an object is not an *ES5* native object, since it
> has a [[Class]] value not defined by the ES5 spec. By the note on the
> host object definition, it is therefore (to ES5) a host object.
>
> Perhaps Garrett's function should be renamed isES5HostObject for
> clarity. With that new name, I would feel comfortable using and
> recommending use of that function.
>  
>
>
>     The starting point of this discussion seems to be the desire to find
>     a reliable way to discriminate  "host objects".  ES5 wasn't
>     intentionally trying to provide such a mechanism and I don't believe
>     that it accidently did so.
>
>
> I agree that we did not intend to provide such a discrimination
> mechanism. But I do think we accidentally did so.
>
>  
>
>
>     Allen
>
>
>
>
> --
>     Cheers,
>     --MarkM
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Mark S. Miller-2


On Thu, Jul 22, 2010 at 11:16 PM, David Flanagan <[hidden email]> wrote:
Allen,

The host vs. native distinction has long bothered me as well.  Thanks for a particularly lucid explanation.  In the next edition of the spec, perhaps you could go further and eliminate the use of the word "host" altogether, leaving you with only native objects and non-native objects.  Then you don't have to say that host objects can be native, or non-native.

Garrett,

You could drop the confusing word "host", too.  If you invert the boolean sense of your function then you can call it isNativeObject() or isNativeValue() or just isNative().

I submitted similar comments to Allen while the spec was in its public review phase.  I didn't feel strongly about getting it fixed, however, because the ambiguous definitions in question are in a non-normative portion of the spec.  (All of section 4, including the definitions are non-normative.)

And tangentially related to the original question about the nature of alert, and tangentally related to the notion of accidentally provided discrimination mechanisms, here is how to determine whether an ES5 object (native or non-native) is callable.  It relies on the fact that forEach() tests for callability before checking for an empty array.

Object.isCallable = function(o) {
   // Array.prototype.forEach throws TypeError for non-callable args
   try {
       [].forEach(o);  // o will never be invoked since array is empty
       return true;
   } catch (x) {
       if (x instanceof TypeError) return false;
       else throw x;
   }
};

Clever!

Fortunately, for this one, you can simply ask

    typeof o === 'function'

See table 20 in 11.4.3

 

Of course I don't have an ES5 implementation with callable objects that are not functions to test it out on.

       David

Mark S. Miller wrote:
On Mon, Jul 19, 2010 at 2:35 PM, Allen Wirfs-Brock <[hidden email] <mailto:[hidden email]>> wrote:

    > -----Original Message-----
    > From: Mark S. Miller [mailto:[hidden email]
   <mailto:[hidden email]>]
    > Sent: Monday, July 19, 2010 2:02 PM
    > >
    >> Do we??  What do you think "host object" means?
    >
    > Objects that are not native objects. I.e., the categories are
   disjoint and Garrett's
    > isHostObject method is correct.
    >

   Ok, I think we generally agree.  "host object" as used in the ES5
   spec. in essentially all cases means  "not native object".
    Garrett's isHostObject test would arguably almost be valid if used
   within a perfectly conforming and unextended ES5 implementation.
    However, a conforming implementation is allowed to "provide
   additional types, values, objects,..." and such extensions might
   include the use of new [[Class]] values.  For example, the JSON
   object is semantically a perfectly normal native object but has a
   distinct [[Class]] value.  If an implementation included a different
   but similar extension isHostObject would classify it as a "host
   object".  Whether or not you are happy with that result probably
   depends upon your isHostObject use case.


I agree. FWIW, I am happy with that result. By the definition of ES5 "native object", such an object is not an *ES5* native object, since it has a [[Class]] value not defined by the ES5 spec. By the note on the host object definition, it is therefore (to ES5) a host object.

Perhaps Garrett's function should be renamed isES5HostObject for clarity. With that new name, I would feel comfortable using and recommending use of that function.
 

   The starting point of this discussion seems to be the desire to find
   a reliable way to discriminate  "host objects".  ES5 wasn't
   intentionally trying to provide such a mechanism and I don't believe
   that it accidently did so.


I agree that we did not intend to provide such a discrimination mechanism. But I do think we accidentally did so.

 

   Allen




--
   Cheers,
   --MarkM


------------------------------------------------------------------------

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [[Class]] Property of Host Object

Garrett Smith
On 7/22/10, Mark S. Miller <[hidden email]> wrote:

> On Thu, Jul 22, 2010 at 11:16 PM, David Flanagan
> <[hidden email]>wrote:
>
>> Allen,
>>
>> The host vs. native distinction has long bothered me as well.  Thanks for
>> a
>> particularly lucid explanation.  In the next edition of the spec, perhaps
>> you could go further and eliminate the use of the word "host" altogether,
>> leaving you with only native objects and non-native objects.  Then you
>> don't
>> have to say that host objects can be native, or non-native.
>>
>> Garrett,
>>
>> You could drop the confusing word "host", too.  If you invert the boolean
>> sense of your function then you can call it isNativeObject() or
>> isNativeValue() or just isNative().
>>

Changing the name would not make it interoperable with all released IE
versions.

The problem of isNativeObject can mostly be avoided.

[...]

> Fortunately, for this one, you can simply ask
>
>     typeof o === 'function'
>

Yes, and much shorter than David's example and it still only holds
true in ES5 implementations, so not interoperable.

The other consideration with David's example is if it is used with any
library that adds Array.prototype.forEach, and many do. In that case,
David's `isCallable` would return true for anything, even if it was
not passed anything at all:

Array.prototype.forEach = function(fun , context) {

Now most of the time, web sites check first, as the examples on MDC
have long advocated, however there are many copy'n'pastes of what I
see on Twitter.com. I've posted this on comp.lang.javascript -- have
you noticed this?


http://a2.twimg.com/a/1279831293/javascripts/twitter.js
(alternatively:
<http://a2.twimg.com/a/1279831293/javascripts/twitter.js?1279833486>)


// Source code for Twitter.com:
if(!Array.forEach) {
  Array.prototype.forEach = function(D, E) {
    var C = E || window;
    for(var B=0, A = this.length; B < A;++B) {
      D.call(C,this[B],B,this)
    }
};

  Array.prototype.map=function(...

The same strategy was copy'n'pasted to the company "CoTweet", also a
jQuery shop.

The source of this may be Twitter employee Dustin Diaz:
  http://www.dustindiaz.com/sugar-arrays/
The code seen on Twitter.com looks strikingly similar, using `window`
as global object, using pre increment instead of post increment, not
checking to see if it is a sparse as if(`i in this`){ ... }, yet it is
different than Prototype's each.


And so using David's 'isCallable', we could have
var nothingIsCallable = isCallable(); // true on Twitter.com

Same problem with Function.prototype.bind checks:
function isCallable(obj) {
  try {
    Function.prototype.bind(obj, null);
    return true;
  } catch(ex) {
    return false;
  }
}

Harmony should differentiate between non-native and native objects.

Constructs such as that should not be depended upon.

Garrett
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss