Agreed, but if you threat __proto__ as a different descriptor you also add
extra complexity.
Why not making as any other Object.prototype property exposing getters and
setters since these are what they are?
You have to add a description of these two and everything else will be
consistent with all other descriptors.
You will also make possible, eventually, to have a __proto__ free
environment where only the "main" program could hold and use "for good"
that descriptor.set magic behavior
On Sun, Apr 21, 2013 at 11:20 AM, Allen Wirfs-Brock
<al...@wirfs-brock.com>wrote:
>
> On Apr 21, 2013, at 10:03 AM, Brendan Eich wrote:
>
> > Allen Wirfs-Brock wrote:
> >> On Apr 21, 2013, at 5:22 AM, David Bruant wrote:
> >>> Hi Axel,
> >>>
> >>> Le 21/04/2013 01:37, Axel Rauschmayer a écrit :
> >>>> __proto__ can be globally switched off by deleting
> Object.prototype.__proto__. I’m assuming that that is useful for
> security-related applications (Caja et al.). But I’m wondering: doesn’t
> that go too far? I’m seeing three ways of using __proto__:
> >>>>
> >>>> 1. Read the [[Prototype]] of an object. Already possible via
> Object.getPrototypeOf().
> >>>> 2. Set the [[Prototype]] of a fresh object created via an object
> literal (i.e., an alternative to the rejected <| operator). Already (kind
> of) possible via Object.create().
> >>> Also possible with class syntax and the "extends" keyword (with all
> the @@create internal semantics).
> >>>
> >>>> 3. Mutate the [[Prototype]] of an existing object.
> >>>>
> >>>> Globally, I would only want to switch off #3.
> >>> You can re-enable #1 by re-adding Object.prototype.__proto__ as your
> own getter wrapping Object.getPrototypeOf. Or maybe instead of "delete
> Object.prototype.__proto__", just do:
> >>> Object.defineProperty(Object.prototype, "__proto__", {set:
> undefined});
> >>
> >> I still think that Dunder proto should not be exposed at all by
> Object.getOwnPropertyDescriptor (or any other reflection) and that there
> is no need to leak either a working or always throwing __proto__ setter
> function into the hands of a ES programmer.
> >
> > This isn't what we seemed to agree on at past TC39 meetings.
> >
> > It's also not what the engines trying to converge on ES6 semantics have
> implemented.
>
> It's not clear to me, yet what convergence we actually have.
>
> Regardless, it's only observable via
> Object.getOwnPropertyDescriptor(Object.prototype, "__proto__") which in my
> proposal returns undefined when Dunder proto is active and in other
> proposals returns a function that when evaluated throws something. The
> semantics of Dunder proto that have been discussed isn't just that of an
> accessor property and can't be purely implemented as such so I no value in
> trying to masquerade it as an accessor for getOwnPropertyDescriptor.
> Returning get/set functions that always throws is just adding complexity
> that delivers no value.
>
> Allen
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
