Call for opinions: attribute defaults and renaming "flexible"

Garrett Smith dhtmlkitchen at
Fri Sep 5 18:02:09 PDT 2008

On Fri, Sep 5, 2008 at 5:19 PM, Ingvar von Schoultz
<ingvar-v-s at> wrote:
> Brendan Eich skrev:
>> On Sep 5, 2008, at 4:33 PM, Ingvar von Schoultz wrote:

>> 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 :-(.

But seems to have been the spirit of assigning to a property that has
a getter and no setter. That throws, if I'm not mistaken.

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

The attributes (ReadOnly, DontDelete, DontEnum) were kind of hidden to
the user and I think that's what the getPropertyDescriptor is trying
to address. It seems that the only way to detect ReadOnly is to try to
set a value and then check to see if it was successful. Knowing ahead
of time what is ReadOnly is more useful. It's not usually a problem.
For example:

function x(){ }
x.length++; // can't do it;
=> 0

You probably knew it but just didn't know it.


> --
> Ingvar von Schoultz

More information about the Es-discuss mailing list