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.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
