Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

Brendan Eich brendan at
Mon Oct 1 16:41:41 PDT 2012

Norbert Lindenberg wrote:
> On Oct 1, 2012, at 15:53 , Brendan Eich wrote:
>>> 2) BuiltIn.prototype has state that lets BuiltIn methods successfully operate on the object, at least as long as they don't modify the state.
>>> True for ES5 objects, currently also true for ES Internationalization objects. This means Intl.Collator.prototype can be used as a Collator with default properties, which applications might find useful. Discussion so far inconclusive.
>> Mark has a conclusion: don't hide mutable state behind accessors in a prototype. The reason is that Object.freeze can't freeze such state. Is Intl.Collator.prototype's state hidden that way, or exposed to Object.freeze?
> All state in Collator&  Co. instances is hidden in internal properties, but we don't provide any means to modify the state after construction.

So the state is immutable after construction?

>>> 3) The state mentioned in 2) is modifiable.
>>> True for some ES5 objects (Array, Date, RegExp),
>> Don't forget Object :-P.
> I'm thinking of state that goes beyond an empty object and makes a BuiltIn instance function as a BuiltIn instance. Object instances have no such state.

Can Arrays? Remember, 'length' is observable just a data property and 
the custom [[DefineOwnProperty]] or [[Put]] hook is not state.

>   Of course any prototype object is created extensible, so you can add properties that aren't relevant to its being a BuiltIn instance.

Indeed (see below).

>>>   not true for ES Internationalization objects. The discussion seems to conclude that modifiable prototype objects are a bad idea.
>> I'm not sure -- I would say the known problem is hidden (to Object.freeze) mutable state, not data properties such as RegExp.lastIndex. Mark should confirm.
> Mutable state that can't be frozen is particularly dangerous, but there were also objections to having Map.prototype or Array.prototype as global storage bins.

That's no more an issue than any unfrozen prototype including Object, 
which is what we're discussing (DavaView.prototype is an Object instance).

The issue is the unfreezable mutable hidden state, which makes a side 

>>> 4) Object.getPrototypeOf(BuiltIn.prototype) returns BuiltIn.prototype.
>>> False for ES5 objects and ES Internationalization objects. This would lead to infinite loops when looking up properties that don't exist, and we probably don't want that.
>> Yes, this makes no sense, not a goal in any scenario.
>>> 5) BuiltIn.prototype instanceof BuiltIn evaluates to true.
>>> False for ES5 objects and ES Internationalization objects. The ES5 spec for instanceof relies on 4).
>> Indeed this cannot be true given that o instanceof C always gets o's [[Prototype]] before matching against C.prototype -- always hops "one up the chain".
> If 4) were true, you'd have an infinite chain, so one hop wouldn't be an issue at all.

But 4 is false :-P. I was going in order, but if you want to make these 
independent, then ok!


More information about the es-discuss mailing list