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

[Brendan Eich]

Mark S. Miller wrote:
> On Sat, Sep 29, 2012 at 5:17 PM, Brendan Eich <brendan at mozilla.org 
> <mailto:brendan at mozilla.org>> 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
>
> http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
> http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps
> 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?

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

/be