On object extension

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Nov 28 21:51:18 PST 2011

On Nov 29, 2011, at 3:58 PM, Brendan Eich wrote:
> ...
> So don't check, let the program fail.
> The problem with the latter (i.e., with "[doing] its best to extend the object" is that you could end up with a bad combination of old and new properties.
> There's no silver bullet here. If we want something (syntax TBD) as a special form for "extend this object with these literal properties", we as programmers have to choose a policy. JS standardizers must agree on the default policy.
> This is tricky but simpler is better. People have been using PrototypeJS's extend for ages, but in a world with no real non-configurable and/or non-writable properties on user-defined objects. So Prototype's extend doesn't shed much light on the future.
> The http://traitsjs.org/ work is a bit freeze-happy and closure-costly, but it can be used today. Are people using it? I recall Bespin (now Cloud9) tried it but the closure costs (per method per instance) were too high.
> Choosing default conflict policy before we have experience is a mistake, but if we must choose now, I think throwing is the only sane answer. We can relax it (via new "knobs" to twist) later if need be.
> /be

I really don't have much to add to what Brendan said.  I spec'ed it the way I did because it is better to consistently reuse an existing policy than to make up a new policy for each new situation. In practice, I expect such extensions to be used in a manner such that they will seldom fail.  If you are merging properties into an arbitrary and unknown shaped object then you probably need to define your own policy and do you own case analysis so .{ } is probably not what you need to use in that case.  Neither is Object.defineProperties.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111129/c5e71460/attachment-0001.html>

More information about the es-discuss mailing list