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