direct_proxies "problem"

Nathan Wall nathan.wall at live.com
Thu Jan 10 21:46:21 PST 2013


David Bruant wrote:
> For the long term, I expected DOM objects could be proxified. 
> Boris convinced me otherwise for DOM Nodes at least. 

Are you so convinced that the `unknownPrivateSymbol` trap is necessary?

> It's been decided early that a Proxy.isProxy method should be avoided, 
> because proxies should be indetectable from the objects they try to 
> emulate from the ECMAScript perspective


I thought part of the goal in ES6 was striving to make the DOM emulable (dare I say implementable?) in pure ES. If that's the case, the inability of DOM objects to be proxied sounds like a big deal.

(A) If a proxy is allowed to have a DOM node as its target, but `element.appendChild(proxiedNode)` throws, then you can detect if an object is a proxied DOM node based on whether it throws when you call `appendChild`:

    function isNodeProxy(node) {
        try {
            return node instanceof Node &&
                document.body.appendChild(node) &&
                !!document.body.removeChild(node);
        } catch(x) {
            return false;
        }
    }

(B) If a proxy isn't allowed to have a DOM node as its target and ES objects have no way to refuse being proxied, then the DOM is allowed to do something ES can't, widening the gap.

A consistent approach might be having some way for an ES object to refuse being proxied, but It still sounds to me like the real problem is the `unknownPrivateSymbol` trap.

If you take this trap away, wouldn't that let DOM objects be proxied? If you leave this trap there, library authors who want the same level of integrity as the DOM developers want will avoid symbols and try to come up with a WeakMap solution (which will require a bit of legging to work with inheritance I now realize, but I think it can be done).  Who knows, if a good enough WeakMap micro-library is worked out that can come close to simulating symbols without the `unknownPrivateSymbol` problem, private symbols may even become an anti-pattern. Or security-minded developers might just retreat back into closure-classes. Are there good enough reasons to leave the `unknownPrivateSymbol` trap at such an expense?

What does `unknownPrivateSymbol` gain? Someone can always write around it with WeakMaps and closures.  One thing I have read is it could help in the case of a read-only proxy which would throw anytime `unknownPrivateSymbol` is called with a "set" invocation, but that doesn't really ensure an object is any more read-only than without `unknownPrivateSymbol` if the object just avoids symbols. If you really want to ensure an object's properties are read-only, I think you need to have the proxy store the first call to the get-related traps to store the value of each property the first time the trap is invoked and ensure that that same value is returned for every subsequent call to the trap for the same property.

In addition, trying to make an object read-only in this way seems to be in conflict with the fact that private symbols are immune to freezing. I assume private symbols are immune to freezing because they represent internal state in the same way that variables inside closures can represent internal state. Why then are we allowing proxies to cancel writes to private symbols it doesn't know about?

Nathan 		 	   		  


More information about the es-discuss mailing list