[[Class]] Property of Host Object

[Mark S. Miller]

On Fri, Jul 16, 2010 at 9:54 PM, Garrett Smith <dhtmlkitchen at gmail.com>wrote:

> I have a question reqarding [[Class]] property as defined In ES5:
>
> | The value of the [[Class]] internal property of a host object
> | may be any String value except one of "Arguments", "Array",
> | "Boolean", "Date", "Error", "Function", "JSON", "Math", "Number",
> | "Object", "RegExp", and "String"
>
> May it be something other than a string value? Or must it be a string
> value?
>

It must be a string value.


>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100716/4b890717/attachment.html>