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

Mark S. Miller erights at
Sat Sep 29 22:21:20 PDT 2012

On Sat, Sep 29, 2012 at 10:14 PM, Brendan Eich <brendan at> wrote:

> Mark S. Miller wrote:
>  On Sat, Sep 29, 2012 at 5:17 PM, Brendan Eich <brendan at<mailto:
>> brendan at>> wrote:
>>     Allen Wirfs-Brock wrote:
>>         However, there is a bigger issue here.  You could have asked a
>>         similar  question about Map.prototype.  Why isn't
>>         Map.prototype a Map instances? Is this a bug or an intentional
>>         design decision?
>>         Historically, the prototype objects associated with the 9
>>         named built-in constructors were all defined to be instances
>>         of those constructors.  For example, Boolean.prototype is a
>>         Boolean instance whose value is false.
>>         In writing the specification for Map, I intentionally deviated
>>         from that pattern.
>>     Failing to consult with implementors will just make editing churn.
>>     I don't remember much discussion on this change,
>> FWIW, this isn't a change from what we've discussed, it's a return to
>> what we've discussed. The proposals at
>> and
>> all the accepted class proposals including the recent maximin classes
>> use prototypes as Allen is now using them -- essentially as vtables,
>> rather than prototypical instances.
> That conclusion assumes too much. You don't need Object instance
> prototypes. You simply need immutable/degenerate/unusable prototypes of the
> same class as the constructor instantiates.
> Did you read further down?

(sheepishly) I did after.

>      Your change requires implementations to provide a different
>>     built-in class (constructor/prototype) initialization path. That's
>>     not desirable _per se_. Neither IMHO is the user-facing semantic
>>     split among "old" and "new" constructors.
>>     There are two separate issues here:
>>     1. Should Map.prototype be an instance (firstborn for its realm)
>>     of class Map?
>>     2. Should Map.prototype be a key/value store that can be used or
>>     abused as any other Map could be?
>>     We should not mix these up. SpiderMonkey (and possibly V8, I
>>     haven't tested) says "yes" to 1 and "no" to 2.
> V8 and SpiderMonkey agree. This avoids making two paths for built-in
> constructor.prototype creation, one that makes a degenerate firstborn of
> the class at hand, the other than makes an Object-instance prototype.
> Why introduce this irregularity if it's not necessary to avoid the
> communication channel?

I agree that the only security issue is avoiding the communications channel.

Security aside, given maximin

    class Foo

what do you suggest Foo.prototype be?

> /be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list