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

Norbert Lindenberg ecmascript at
Sat Sep 29 22:48:38 PDT 2012

Last week TC 39 approved a standard defining three new built-in constructors whose instances and prototype objects all have [[Class]] "Object". Also, the prototype objects are not constructed by their respective constructors, but initialized by them, e.g., as{}).

Are you suggesting they should have "Collator", "NumberFormat", and "DateTimeFormat", respectively, and the prototypes be specified as being constructed by their constructors?


On Sep 29, 2012, at 22:24 , Brendan Eich wrote:

> Mark S. Miller wrote:
>> Security aside, given maximin
>>    class Foo
>> what do you suggest Foo.prototype be?
> If classes are sugar for constructor functions, an Object instance, just as you'd get for
>  function Foo(){}
>  Foo.prototype
> There has always been an unsightly difference between built-in constructors and user-defined ones. Whether or how we reduce that gulf is separable from what the [[NativeBrand]] or [[Class]] of a built-in's prototype should be.
> When self-hosting built-ins, this matters. Suppose [[NativeBrand]] could be a symbol private to the built-ins. That would allow the engine to set up bespoke-looking prototypes as it needs to for ES1-5 compatibility. But should user-defined classes have access to this symbol?
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list