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
<allen.wirfs-br...@microsoft.com
<mailto:allen.wirfs-br...@microsoft.com>> wrote:
> -----Original Message-----
> From: Mark S. Miller [mailto:erig...@google.com
<mailto:erig...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
