Call for opinions: attribute defaults and renaming "flexible"

Brendan Eich brendan at
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> 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 mailing list