strawman for the := operator

David Herman dherman at
Wed Aug 8 15:00:34 PDT 2012

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.


More information about the es-discuss mailing list