strawman for the := operator

John J Barton johnjbarton at
Wed Aug 8 17:19:13 PDT 2012

On Wed, Aug 8, 2012 at 4:52 PM, Brendan Eich <brendan at> wrote:

> David Herman wrote:
>> On Aug 8, 2012, at 3:08 PM, Axel Rauschmayer wrote:
>>  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.
> It's an anti-pattern, in general: constants go on constructors or in
> "package" objects. Too many colllision and deep-mutable hazards on the
> proto-chain for advisory constants.
>  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").
> I made the same argument but reached a different conclusion: proto-chain
> walking not wanted for Object.extend, because if people *did* extend
> Object.prototype, lots of for-in uses, especially including the one in
> Prototype's Object.extend, would break.

Perhaps the current practice is not a great resource for making decisions
here. I'm not up on jQuery, but the most common pattern I've seen for
extend()-ish methods is to apply them to .prototype properties, with two
unspoken and unchecked constraints: only add functions to .prototype
objects and don't dynamically modify base prototypes to affect derived
ones. That is, the extend() is used to help implement classical
inheritance.  In this case, the difference between own and chain copies is
minor performance issues.  Perhaps that explains both the variation among
extend() implementations and the lack of own-checks: in practice it's not
so important either way.

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

More information about the es-discuss mailing list