Kevin Smith wrote:
Define Properties Operator
http://wiki.ecmascript.org/doku.php?id=strawman:define_properties_operator
Batch Assignment Operator
http://wiki.ecmascript.org/doku.php?id=strawman:batch_assignment_operator
(via
dherman)
It's not clear to me that a batch assignment operator would obviate
the need for similar library functions in the wild. Sometimes one
wants to overwrite the properties of the target object, but other
times one only wants to set a value when the target object does not
already have a property defined for that name (as in underscore's
"defaults").
A batch-assignment operator in this way is similar to a flat-head
screwdriver. Nice to have, but you're still going to need to go to
the hardware store to assemble that dresser from Ikea.
Nicely put.
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]]).
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).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
