setPrototypeOf vs obj.__proto__ assignment

[Andrea Giammarchi]

nope, if you have a dict and you use __proto__ nothing should happen,
that's why Object.setPrototypeOf is suggested: it's more powerful + it does
not show up in getOwnPropertyNames as '__proto__' does so it's shenanigans
and errors prone.

__proto__ is not even more elegant than Object.create(null) plus you can
use a piece of code that fits in a tweet to simplify its equivalent usage
when meant.

```javascript
var o = Object.setPrototypeOf(
  {
    // your literal object
  },
  Object.prototype // your inherited proto
);
```

wanna simplify that ? [here just an example](
https://gist.github.com/WebReflection/9900019)

```javascript

*var* O*=function*(O,s){s*=*O.setPrototypeOf*||function*(o,p){o.__proto__*=*
p;*return* o};*return* *function*(p,o){*return* o*?*s(o,p)*:*p*||*s({},p)}}(
Object);


var obj = O(null, {

  // your literal Object

});


// same as

var obj = O(

Array.prototype,

{}

);
```

Most `__proto__` support is completely broken these days when it comes to
dictionaries ... since `{__proto__:null}.__proto__` still shows up and the
only fix is to `delete Object.prototype.__proto__` where possible, or reuse
its setter so simulate `Object.setPrototypeOf` when it's not poisoned.

All this has been discussed for years now ... it's surprising it's still
not clear why the explicit `Object.setPrototypeOf` is the preferred choice.

It feels like everyone uses `__proto__` on daily basis while ES6 promotes
classes ... so either `__proto__` is not a real world use case, or `class`
landed for no reason, IMO.











On Mon, Apr 7, 2014 at 8:53 AM, John Barton <johnjbarton at google.com> wrote:

> The context for my question was Tom van Cutsem's excellent Proxy shim,
> https://github.com/tvcutsem/harmony-reflect, which uses __proto__
> assignment to shim Object.setPrototypeOf.  In developing Proxy code,
> objects and not classes are relevant.  Directly manipulating the __proto__
> is vastly superior to any solution based on es6 classes or our unfortunate
> friend Object.create().
>
> jjb
>
>
> On Mon, Apr 7, 2014 at 2:34 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
>
>> I like __proto__ in object literals, as a nicer Object.create(). In that
>> case, __proto__ is "the new <| operator" and really quite different from
>> __proto__ as a getter and a setter.
>>
>> I have two uses for it:
>>
>> - Dict pattern { __proto__: null, ... }
>> - To explain prototype chains to beginners (=> not something that would
>> be used in production code).
>>
>> If ECMAScript 6 didn't support classes and subclassing, it would help
>> with subclassing, too.
>>
>>
>>
>>
>> On Apr 7, 2014, at 11:05 , Andreas Rossberg <rossberg at google.com> wrote:
>>
>> > On 4 April 2014 19:49, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> >> __proto__ is there for legacy compatibility.
>> >> setPrototypeOf should be preferred for new code
>> >
>> > For new code, neither should be used.
>> >
>> > /Andreas
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
>> --
>> Dr. Axel Rauschmayer
>> axel at rauschma.de
>>
>> home: rauschma.de
>> twitter: twitter.com/rauschma
>> blog: 2ality.com
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> 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/20140407/39fce094/attachment.html>