Agreed, getOwnPropertyNames is way more appropriate if the topic is: use all ES5 features for mixins too.
Also, the Nicolas example is potentially disaster prone, not in that specific form, but in the way a getter with private scope access could be. Imagine many objects using that specific object as mixin with that name getter, if there was a setter too the first one that will use it will overwrite the returned value for all other objects. I think propertie swith getters and setters will cause as many headaches as objects and arrays in function prototypes did before already but hey, if you know what you are doing, I believe there's no other solution for "universally capable mixin method" br On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote: > > On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote: > > > > > On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock <al...@wirfs-brock.com > > wrote: > >> I'm the past we discussed issues surrounding the semantic differences >> between "put" and "define" and we've agreed to include Object.assign in >> ES6. We have also discussed Object.define but have not yet made a decision >> to include it. >> >> Nicholas Zaka recently posted a short article that addresses issues >> relating to the assign/define distinction >> http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/ >> as they already surface in ES5. >> >> For me, this article reenforces that we really need to have something >> like Object.define in ES6. >> >> It also made me think that perhaps Object.mixin might be a more intuitive >> name for such a function. >> > > This name is certainly more real-word-friendly. > > The example code that follows "A pure ECMAScript 5 version of mixin() > would be:" is basically what I imagined Object.define would be, but with a > slight modification in that Object.assign returns the target object, so > should Object.mixin: > > > Except, > 1) It needs to iterate own keys, not just string valued property names so > it will pick up properties whose keys are symbols > 2) It needs to rebind super references > 3) I don't see any reason that it should be restricted to enumerable > properties. If the intend is to deprecate enumerable along with for-in then > we should be adding new functionality that is sensitive to the state of the > enumerable attribute. > > Allen > > > > > > Object.mixin = function(receiver, supplier) { > return Object.keys(supplier).reduce(function(receiver, property) { > return Object.defineProperty( > receiver, property, Object.getOwnPropertyDescriptor(supplier, > property) > ); > }, receiver); > }; > > > var a = {}, name = "Rick"; > > var b = Object.mixin(a, { > get name() { > return name; > } > }); > > console.log( a.name ); // "Rick" > console.log( b.name ); // "Rick" > console.log( a === b ); // true > > > Rick > > > > _______________________________________________ > 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