On Aug 8, 2012, at 11:23 AM, Brendan Eich wrote: > The other advantage of an Object.extend or Object.update function is that > developers can polyfill. Yes, Object.extend in JS libraries relies on for-in > -- but Object.prototype is verboten, so that's mostly ok by convention. > > The point is not that we should standardize Object.extend self-hosted via > for-in, as in PrototypeJS. Rather, we would maximize developer utility and > avoid the need for ES6->ES5 compilers if we were to provide an Object.update > or Object.assign (let's call it) that copies own properties of its second > argument into its first, shallow copying as if by assignment ([[Put]], not > [[DefineOwnProperty]]).
I'm not yet convinced that Object.update should be restricted to own properties. If you're only using object literals, then yeah, you want own properties only; you're basically using object literals as a poor man's named arguments. But if you're just taking an arbitrary object, there's less reason to expect that its relevant properties won't be inherited. > This [[Put]] not [[DefineOwnProperty]] argues for the Object.assign name. The > "assign" trope argues against processing 3rd, etc. actual arguments like the > 2nd (as some library variants of Object.extend do). Object.assign sounds pretty good. But I do like Object.update. Somehow the latter seems more evocative of what the programmer's trying to accomplish, rather than naming it in terms of a language mechanism. Dave _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
