[[Class]] Property of Host Object

[Mark S. Miller]

On Thu, Jul 22, 2010 at 11:16 PM, David Flanagan <david at davidflanagan.com>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 <
>> Allen.Wirfs-Brock at microsoft.com <mailto:Allen.Wirfs-Brock at microsoft.com>>
>> wrote:
>>
>>     > -----Original Message-----
>>     > From: Mark S. Miller [mailto:erights at google.com
>>    <mailto:erights at google.com>]
>>     > 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
>> 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/20100722/ae938d92/attachment.html>