[[Class]] Property of Host Object

Mark S. Miller erights at google.com
Mon Jul 19 15:00:06 PDT 2010

On Mon, Jul 19, 2010 at 2:35 PM, Allen Wirfs-Brock <
Allen.Wirfs-Brock at microsoft.com> wrote:

> > -----Original Message-----
> > From: Mark S. Miller [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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100719/2083023f/attachment.html>

More information about the es-discuss mailing list