Call for opinions: attribute defaults and renaming "flexible"

Ingvar von Schoultz ingvar-v-s at comhem.se
Mon Aug 25 15:03:23 PDT 2008


Mark S. Miller wrote:
>> I ask because I was dismayed to see that ES3.1 will fail silently
>> if you try to assign to a const in non-cautious mode. This is hard
>> to debug. You'll have to avoid this const and instead use let or
>> var. Then errors will be better contained and easier to understand
>> and trace down.
> 
> We expect to change "cautious" to "strict", so I'll use "strict" below.
> 
> Interesting point. We may have let property semantics again needlessly
> corrupt variable semantics. Non-strict assignment to a non-writable
> property must fail silently for legacy compatibility.

Silently failing on properties has the same problem -- symptoms far
away from the bug, debugging gets expensive. Entrenching such an
expensive bug in the language for all future is a serious matter,
and deserves very careful thought, in my opinion.

Would the following be too expensive? If the user configures a
property, we assume that he wants to be told. So when you call
Object.defineProperty(), an internal object-wide flag is set,
[[ConfiguredByUser]], which enables throwing on forbidden write
to any of the object's properties.

Or maybe name the flag [[BecomeWellBehaved]], and remove several
legacy issues. Configuring becomes an opt-in that makes objects
behave better.

I'm curious about the legacy problem. It makes me wonder if the
nature of the problem can suggest a cheap solution.

> I agree that this should throw regardless of
> strictness.

I'm happy to hear that. I hope nothing will prevent it.

> Where in the draft ES3.1 manual did you spot this?

I spotted it in archived email discussions from before my arrival
here. The ES3.1 spec draft of Aug 18 confirms it, see 11.13.1 and
11.13.1.1 (page 69).

>>> As an unfortunate implication
>>> of legacy issues, a non-configurable writable data property may be
>>> made non-writable. If it weren't for this special case, we'd have to
>>> split deletable from configurable.
>> That sounds amazing since no legacy code can call the configuring
>> function. Do you have a link to a discussion or information about
>> this?
>>
>> Of course this is just curiosity, but it really sounds very intriguing.
> 
> Legacy demands that new properties added to the global object by
> assignment or top-level declarations start as non-deletable but
> writable. But runtimes for secure subsets of ES, like ADSafe and Caja,
> need to be able to freeze the global object of their frame during
> their initialization. If not for legacy, we could make new properties
> of the global object start as configurable. If deletable and
> configurable were distinct, we could make new properties of the global
> object start as configurable but not deletable. However, adding
> another attribute to deal with this one problematic case seemed
> overkill. Allowing non-configurable properties to be made non-writable
> seems like the simplest adequate solution.

Could this be solved with a [[BecomeWellBehaved]] flag? Before
anything else is put on the global object, ADSafe and Caja could
make a configuration call on the global object. The resulting
Well-Behaved global object sets [[Configurable]] on all new
variables.

If that's not suitable, ADSafe and Caja might use try-catch.
Always throw when the program tries to make a non-configurable
property non-writable, except if there are two calls in quick
succession to Object.freeze() on the global object, called not
from within a function but from the global scope. Only then
make the change.

Or, as a last resort, turn this into special semantics of
Object.freeze() only, not Object.defineProperty(). It does
make sense for a drastic function like Object.freeze() to
have drastic powers.

>>> If an object is non-extensible and all of its own properties are
>>> non-configurable, then it is _sealed_.
>> I think _locked_ would be more concrete, and Object.lock().
> 
> As Brendan says, in code, "lock" will suggest mutex and concurrency control.

Oops! But of course. Sorry!

I've spent too many years living a sheltered JavaScript life without
seeing such things.

-- 
Ingvar von Schoultz



More information about the Es-discuss mailing list