Call for opinions: attribute defaults and renaming "flexible"
brendan at mozilla.org
Fri Sep 5 16:38:13 PDT 2008
On Sep 5, 2008, at 4:33 PM, Ingvar von Schoultz wrote:
> Ingvar von Schoultz skrev:
>> Mark S. Miller skrev:
>>> On Fri, Sep 5, 2008 at 2:33 PM, Ingvar von Schoultz
>>> <ingvar-v-s at comhem.se> wrote:
>>>> and silent failures
>>>> are often very expensive to debug.
>>> I don't understand. As currently proposed, Object.freeze always
>>> succeeds. What silent failure are you concerned about?
>> If you set a property to non-configurable it means you don't
>> want it reconfigured. If code is still allowed to change it
>> from writable to non-writable, this is a silent failure of
>> the guard against reconfiguring.
> Another silent failure, much more expensive, is when you try
> to write to non-writable properties. (And, apart from this,
> also the related similar problem with constant variables).
This goes back to ES1. In Netscape's original JS implementation, I
reported an error which stopped the script on assignment to read-only
properties (this from memory, I don't have source code for the old
"Mocha" runtime). Without try/catch in ES1, this was viewed as too
harsh by the TG1 group in TC39, leaving only silent-but-deadly
failure to modify the lvalue (the result of the assignment expression
is the unfiltered right-hand-side value, so you can't tell).
This was not revisited when exception handling was added in ES3 :-(.
> I would really like to know the reason for this strange problem
> with non-writable properties, and try to see if there's any way
> a better solution can be found than this seriously expensive
> language bug.
The proposed solution for ES3.1 and beyond is "use strict".
More information about the Es-discuss