On object extension

Brendan Eich brendan at mozilla.com
Mon Nov 28 20:58:41 PST 2011


On Nov 28, 2011, at 1:02 PM, David Bruant wrote:

> Current proposal would turn a configurable non-writable property into a
> writable property which is not a silent error, but rather a big mistake.

A configurable non-writable property is a big mistake. Such a setting has zero integrity, it's "advisory const". You might argue for it in a setting where such advice can be ignored, so the attribute combination is not illegal. But it's nonsensical to argue that some Object.defineProperty variant shouldn't be able to reconfigure to writable such a property.

Whether .{ should be such a variant is of course debatable.


>> Your basically saying "extend obj with { a: 1 } unless doing so would
>> throw an error, in which case fail silently"
>> 
>> Personally I don't like silent failure points.
> I don't see it as a failure. I want to avoid to throw an error when the
> property is non-writable and non-configurable.

Why?


> The problem with a
> syntax-based operator is that it is written once for all.
> -----
> function addABC(obj){
> obj.{a:1, b:2, c:3};
> }
> -----
> Should this function throw whenever the extension is not possible (a
> property is non-writable & non-configurable) as written or do its best
> to extend the object.
> The problem with the former is that to ensure that the assignment won't
> fail, one need to check that for all properties, there is no such
> existing properties that is non-configurable and non-writable (which is
> what i propose to do implicitly).

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


More information about the es-discuss mailing list