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

Norbert Lindenberg ecmascript at norbertlindenberg.com
Mon Oct 1 17:29:51 PDT 2012


On Oct 1, 2012, at 16:41 , Brendan Eich wrote:

> 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?

Correct.

>>>> 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.

length is part of the state, but you're right, sometimes it takes more than state and visible methods.



More information about the es-discuss mailing list