Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)
ecmascript at norbertlindenberg.com
Mon Oct 1 16:29:55 PDT 2012
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.
>> 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. Of course any prototype object is created extensible, so you can add properties that aren't relevant to its being a BuiltIn instance.
>> 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.
>> 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.
More information about the es-discuss