Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)
brendan at mozilla.org
Sat Sep 29 22:14:00 PDT 2012
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
> 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
More information about the es-discuss