possible excessive proxy invariants for Object.keys/etc??
allen at wirfs-brock.com
Wed Nov 21 09:35:34 PST 2012
On Nov 21, 2012, at 9:16 AM, Andreas Rossberg wrote:
> 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.
If you are writing any sort of generic algorithm that does a freeze check on an arbitrary object you have to explicitly perform all of the internal method calls because you don't know whether the object is a proxy (where every such internal method call turns into an observable trap) or even some other sort of exotic object implementation that can observe actual internal method calls. If there is explicit internal state is designate an object as frozen, then we wouldn't have all of those potentially observable calls.
>> 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.
A integrity membranes we are talking about is a higher level abstraction. If that is where the requirements exist then let it do the work. The real question what is it need to do that work and can it be done in a way that doesn't impose a cost for situations that don't have the same requirements. One thing we've talked about in this thread that might be useful is a non-trappable operation that produces a guaranteed accurate list of own property names for an ordinary object.
More information about the es-discuss