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 <d...@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 <bren...@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@wirfs-brock.**com<al...@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@mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
> _______________________________________________
> 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
