strawman for the := operator

Axel Rauschmayer axel at
Wed Aug 8 15:38:59 PDT 2012

>>> 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.
>> Can you elaborate? Because usually, you have instances that point to shared prototypes. Then you’d also want only the own properties. If there is a type hierarchy, all constructors put all instance data in the same object, so you already have an automatic flattening.
> That's a fair point. I have found that I will occasionally have a type-level "constant" that makes sense to keep as an inherited data property, but I'll grant it's somewhat rare.
> Still, the fact that it works fine without the own-check today:
> indicates that code is working fine today without prototype pollution problems (especially given that basically everything on the web breaks if you don't respect "Object.prototype is verboten").
> So before going with the own-check, I'd want to know that existing patterns wouldn't break, and whether it really would help that much.

I can see copying more than the own properties as potentially useful. But then the question is whether one wouldn’t want to preserve the structure. That is, if it was an option, it would be: How long a prefix of the prototype chain to clone? 1 would be the default, 0 or -1 could be used for: “the complete prototype chain”.

Loosely related: I recently looked at _.extend and was surprised that it didn’t copy non-enumerable properties (as far as I can tell, impossible pre ES5) and that it included all inherited properties. OTOH, if you include non-enumerable properties, it becomes impossible to include all inherited properties by default.

Dr. Axel Rauschmayer
axel at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list