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 _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
