Call for opinions: attribute defaults and renaming "flexible"
brendan at mozilla.org
Wed Sep 3 22:58:35 PDT 2008
On Sep 3, 2008, at 10:51 PM, Mark S. Miller wrote:
> On Wed, Sep 3, 2008 at 9:49 PM, David-Sarah Hopwood
> <david.hopwood at industrial-designers.co.uk> wrote:
>> I don't see why any special case is needed here, or why removing it
>> would require splitting [[Deletable]] from [[Configurable]].
>> Suppose that [[Configurable]] = false prevents a writable data
>> from being deleted or changed to non-writable. What compatibility
>> does this introduce? ES3 had no way for user code to change
>> so I don't see how there can be a compatibility problem.
> As I said in an earlier question from Ingvar on the same issue:
> Legacy demands that new properties added to the global object by
> assignment or top-level declarations
Not by assignment -- only by var or function declaration not in eval
> 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.
Except that deoptimizes all high performance JS engines.
> If deletable and
> configurable were distinct, we could make new properties of the global
> object start as configurable but not deletable.
Saving perf but to what end? Does the Caja, etc. programming model
require configurability before freezing for all global props, or a
few, or one?
> 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.
Not arguing, just recapitulating and asking for the Caja use-case.
More information about the Es-discuss