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

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


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

> 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: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120929/8bc6ce2a/attachment.html>


More information about the es-discuss mailing list