On 21 November 2012 17:55, Allen Wirfs-Brock <[email protected]> wrote: > I'd be more favorably inclined towards freezing than I am towards copying. > But, as you know, ES5 does not currently produce frozen objects in these > situations. I feel uncomfortable about enforcing a frozen invariant for traps > where that invariant is not provided by the corresponding ordinary object > behavior. Perhaps I could get over that or perhaps incompatibility applying > that requirement to ordinary objects wouldn't break anything. > > Regardless, freezing and testing for frozen is, itself, not a cheap > operation. It requires iterating over all the property descriptors of an > object. If we are going to build in a lot of checks of for frozen objects > perhaps we should just make frozen (and possibly) sealed object level states > rather than a dynamic check of all properties. Essentially we could > internally turn the [[Extensible]] internal property into a four state value: > open,non-extensible,sealed,frozen. It would make both freezing and checking > for frozen much cheaper.
That doesn't seem necessary, because it is just as easy to optimise the current check for the normal case where the object has been frozen or sealed with the respective operation. > I think it is usually a mistake to perform complex invariant check at low > levels of a language engine. Those often become performance barriers. > Checking complex relationships belongs at higher abstraction layers. Well, the root of the problem arguably lies with the whole idea of proxies hooking arbitrary code into "low-level" operations. Perhaps such power has to come with a cost in terms of checks and balances. There are no higher abstraction layers in this case. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
