Call for opinions: attribute defaults and renaming "flexible"

Ingvar von Schoultz ingvar-v-s at
Fri Sep 5 17:19:21 PDT 2008

Brendan Eich skrev:
> On Sep 5, 2008, at 4:33 PM, Ingvar von Schoultz wrote:
>> 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 :-(.

Interesting, thanks for telling me.

>> 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".

Yes, certainly, but there will always be those who find that
unsuitable, or who find that it breaks the old code that they
must work with. It's very undesirable that the non-strict mode
become bad quality.

Despite lots of years using JavaScript I'm not even aware of any
non-writable properties, so I'm surprised that programs can depend
on them. It's even more strange, then, that program bugs with
clearly incorrect writes to such exotic properties are so frequent
that throwing would break a significant number of programs.

Can these properties be distinguished somehow? Then maybe the
bug can at least be limited to a few old properties.

Ingvar von Schoultz

More information about the Es-discuss mailing list