On Sep 3, 2008, at 10:51 PM, Mark S. Miller wrote: > On Wed, Sep 3, 2008 at 9:49 PM, David-Sarah Hopwood > <[EMAIL PROTECTED]> 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 _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
