Mark S. Miller wrote:
On Sat, Sep 29, 2012 at 5:17 PM, Brendan Eich <bren...@mozilla.org
<mailto:bren...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
