Call for opinions: attribute defaults and renaming "flexible"

Brendan Eich 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  
>> property
>> from being deleted or changed to non-writable. What compatibility  
>> problem
>> does this introduce? ES3 had no way for user code to change  
>> attributes,
>> 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  
code.


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

/be



More information about the Es-discuss mailing list