Addendum: For example, you won’t be able to reliably use Object.assign() to mix an object with methods into a prototype object, because those methods might be non-enumerable.
I think I initially misunderstood you. You think that what I’ve mentioned above is a feature, I’d argue that it is a bug. On Oct 18, 2012, at 4:47 , Axel Rauschmayer <[email protected]> wrote: >>> On Wednesday, October 17, 2012 at 10:27 PM, Axel Rauschmayer wrote: >>>> I’m a bit skeptical about excluding non-enumerable properties for >>>> Object.assign(). I still find enumerability a hard concept to wrap my mind >>>> around, because it pops up in unexpected places. At the moment, it mostly >>>> matters for for...in and Object.keys()/Object.getOwnPropertyNames(). Does >>>> it really make sense to increase its role in JavaScript? >> > >> It's a matter of paving the cow path of least surprise. Imagine if you tried >> to copy the properties and values of a plain object to an object with a null >> prototype and all of those properties you explicitly didn't want were now >> present. > > But those won’t be copied, because only own properties will be copied. I’d be > more worried about adding non-enumerable own properties to an object and > those *not* being copied. > > -- > Dr. Axel Rauschmayer > [email protected] > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer [email protected] home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
