Distinguishing native and host objects
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
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