On Sat, Sep 29, 2012 at 10:14 PM, Brendan Eich <[email protected]> wrote:
> Mark S. Miller wrote: > > On Sat, Sep 29, 2012 at 5:17 PM, Brendan Eich <[email protected]<mailto: >> [email protected]>> 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:simple_maps_and_sets> >> http://wiki.ecmascript.org/**doku.php?id=harmony:weak_maps<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? (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 > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
