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

[Brendan Eich]

Norbert Lindenberg wrote:
> 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 Intl.Collator.call({}).
>
> Are you suggesting they should have "Collator", "NumberFormat", and "DateTimeFormat", respectively, and the prototypes be specified as being constructed by their constructors?

All else equal, yes (sorry for not flagging these).

Any non-equal elses in sight?

/be
>
> Thanks,
> Norbert
>
>
> 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 mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>