Call for opinions: attribute defaults and renaming "flexible"
Mark S. Miller
erights at google.com
Sun Aug 24 15:40:58 PDT 2008
On Sun, Aug 24, 2008 at 2:12 PM, Ingvar von Schoultz
<ingvar-v-s at comhem.se> wrote:
> Mark S. Miller wrote:
>> If a property is _configurable_, it may be deleted, its enumerability
>> may be changed, it may be changed between being a data property (with
>> [[Value]] and [[Writable]]) and an accessor property (with [[Getter]]
>> and [[Setter]]), and it may be made non-configurable, at which point
>> none of these changes remain possible.
> If you try to do something that is disabled by attribute settings,
> does this throw an error or just fail silently?
> 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. But I don't
think there's any corresponding legacy constraint on assignment to a
const variable. I agree that this should throw regardless of
strictness. Where in the draft ES3.1 manual did you spot this?
>> 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
> 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.
>> 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.
More information about the Es-discuss