possible excessive proxy invariants for Object.keys/etc??
rossberg at google.com
Wed Nov 21 09:16:40 PST 2012
On 21 November 2012 17:55, Allen Wirfs-Brock <allen at wirfs-brock.com> 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.
More information about the es-discuss