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