Distinguishing native and host objects

David-Sarah Hopwood david-sarah at jacaranda.org
Wed Sep 2 19:14:36 PDT 2009

Brendan Eich wrote:
> On Sep 2, 2009, at 6:15 PM, David-Sarah Hopwood wrote:
>> Brendan Eich wrote:
>>> The spec can't yet define these "native wannabe" future standardization
>>> fodder objects, but clearly that's what Allen was thinking of, and it is
>>> well-known to implementors.
>> Why do such things need to have a [[Class]] other than "Object"?
> Let's make everything have [[Class]] "Object". Any "private instance
> variables" whose presence is currently guarded by class checks should
> become Name-identified (unforgeable/unguessable property names)
> properties with whatever values are needed. Bonus: you can delegate such
> internal properties to prototypes.
> Seriously, this is not the language we have.

You missed my point. Why do *new* abstractions need to have a [[Class]]
other than "Object"? The fact that existing abstractions are defined that
way is not a sufficiently good reason.

The obvious approach to handling instance properties is that if a needed
property doesn't exist or is of the wrong type, the algorithm should throw
a TypeError.

Note that once the Harmony class system is in place, we'll presumably be
able to specify new abstractions as if they had been defined using classes,
and I would think that we would certainly want to do it that way, regardless
of historical precedent.

[Replies to es-discuss, since this is no longer on-topic for es5-discuss.]

David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

More information about the es-discuss mailing list