B.3.1 The __proto__ pseudo property

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue May 7 13:26:34 PDT 2013


fine for non-extensible objects, you might desire to keep a dictionary a
dictionary though, allowing properties extensions avoiding hot-swap
inheritance

2 options in my mind:

  1. Object.freezeInheritance(generic), setting a [[MutablePrototype]]
internal property to false (true by default)
  2. a new native constructor such Dict/Dictionary with immutable
[[Prototype]] as exception

I rather prefer a first-like option so that second constructor is easy to
implement and any other object can still be used and marked as safe in
terms of inheritance.

This would be really nice, IMHO!




On Tue, May 7, 2013 at 12:18 PM, Mark Miller <erights at gmail.com> wrote:

>
>
>
> On Tue, May 7, 2013 at 11:09 AM, Nathan Wall <nathan.wall at live.com> wrote:
>
>> >> Do you think we can come to some sort of agreement, as discussed
>> below,
>> >> that [[ProtoSetter]] doesn't need to be realm restricted. Such an
>> >> agreement would let us write the simplest possible specification of
>> >> __proto__.
>> >
>> > Very timely question. I've discussed this within the other Cajadores
>> > and the answer is yes. While the range restriction help security in
>> > some ways, it doesn't help a lot, and it actually hurts in other
>> > ways. Such simplicity itself is of benefit to security, and weighs in
>> > the overall tradeoff. On balance we're better off without it. I'll be
>> > posting publicly on this soon.
>>
>> ...
>>
>> >> It would also remove all obstacles to having Object.setPrototypeOf
>> >> which a number of vocal community members would really prefer to have
>> >> built-in and available rather than having to use __proto__ ugliness.
>> >
>> > Yes. All objections to this disappear. And likewise for having proxies
>> > handle trapping proto changes differently from their handling of other
>> > changes.
>>
>>
>> If I didn't misinterpret, this sounds like a very, very a welcome
>> discussion -- one for which I would like to restate that I have a real
>> use-case which is not 100% solvable with realm-confined __proto__[1].
>>
>> I would like to add that, should `setPrototypeOf`, be admitted, it should
>> work on objects which don't inherit from `Object.prototype` in order to
>> settle my use-case (and also from a purist's point of view of how the
>> language should behave). If `setPrototypeOf` is not admitted, I would hope
>> that at least __proto__ will be a setter which can be retrieved with
>> `getOwnPropertyDescriptor` and applied to objects which don't inherit from
>> `Object.prototype`.
>>
>
> Agreed on both. The only restriction we need is the one that ES5 already
> gives us: You can't change the [[Prototype]] of a non-extensible object.
>
>
>
>>
>> Please keep up the discussions around this issue!
>>
>>
>>
>> [1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029329.html
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/7a04379d/attachment.html>


More information about the es-discuss mailing list