B.3.1 The __proto__ pseudo property

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed May 8 16:47:12 PDT 2013


it took 8 years to teach JS developers **not** to pollute Object.prototype,
I understand your concern and I understand with the possibility to drop
enumerability that could (and will) be proposed by someone.

At the same time it will be a stubborn move aim to fix some deprecated,
old, not maintained anymore, library so ... hopefully that won't hurt much
the community.


On Wed, May 8, 2013 at 2:37 PM, Dean Landolt <dean at deanlandolt.com> wrote:

> Call me crazy but I can picture a world where you have to explicitly shim
> in __proto__ (using Object.setPrototypeOf) if you really need it. Not
> anytime soon, sure, but maybe one day. Maybe...
>
>
> On Wed, May 8, 2013 at 5:05 PM, Brendan Eich <brendan at mozilla.com> wrote:
>
>> Having Object.setPrototypeOf to match Object.getPrototypeOf is nice,
>> better for proxies (with necessary changes to them), and polyfillable.
>>
>> Take my last note as an attitude adjustment, though. So long as __proto__
>> endures, its brevity and legacy uses will tend to propagate its use into
>> the future.
>>
>> In that light, pushing everything but the object literal __proto__
>> special form into Annex B still rubs me the wrong way. I'd do both
>> O.p.__proto__ and the special form in the main spec, or both in Annex B (to
>> make Andreas happy ;-). Not split them up.
>>
>> /be
>>
>>
>> Allen Wirfs-Brock wrote:
>>
>>> On May 8, 2013, at 8:46 AM, Andreas Rossberg wrote:
>>>
>>>  On 8 May 2013 17:41, Allen Wirfs-Brock<allen at wirfs-brock.**com<allen at wirfs-brock.com>>
>>>>  wrote:
>>>>
>>>>> On May 8, 2013, at 8:31 AM, Mark Miller wrote:
>>>>>
>>>>>  What about your triangle argument?
>>>>>>
>>>>> There is another way:
>>>>>
>>>>> let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
>>>>>
>>>>> Let's keep {__proto__: foo} in the slightly  disrespectable  Annex B
>>>>> box.  That keeps it together with O.p.__proto and leaves room for future,
>>>>> more elegant object literal syntax extensions if we decided we really need
>>>>> them (and we probably won't).
>>>>>
>>>> Isn't Object.create the proper alternative to both {__proto__: } and
>>>> triangle for objects? What has setPrototypeOf got to do with it? (And
>>>> why is that on the table all of a sudden?)
>>>>
>>>
>>> I think that Brandon Benvie adequated addressed Object.create.
>>>
>>> Regarding setPrototypeOf, once Mark agreed that the [[protoSetter]]
>>> function did not need to be Realm restricted it essentially became a
>>> publicly available API for modify the [[Prototype]] of arbitrary objects.
>>>
>>>        Object.**getOwnPropertyDescriptor(**Object.prototype,
>>> "__proto__").set.call(obj, proto)
>>>
>>> There is a vocal part of the JS community who would prefer that the core
>>> language also offer Object.setPrototypeOf as the preferred alternative to
>>> the above:
>>>
>>>         Object.setPrototypeOf(obj,**proto)
>>>
>>> This is only a cosmetic difference. But I agree that it is good
>>> cosmetics. Dynamic prototype modification seems to have won as a required
>>> feature of the language.  Since that is the case, consistancy suggests that
>>> we should  treat it cosmetically just like all the dynamic reflection
>>> operations defined on Object.
>>>
>>> Allen
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
> _______________________________________________
> 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/20130508/ea0567d7/attachment-0001.html>


More information about the es-discuss mailing list