2011/4/5 David Bruant <david.bru...@labri.fr>
> Le 05/04/2011 10:22, Tom Van Cutsem a écrit :
> > (...)
> >
> > If a browser does not support Object.freeze, seal or
> > preventExtensions, it likely does not support fixing proxies either.
> > Calling the "fix()" trap explicitly via Proxy.trap would still not
> > lead to the expected behavior.
> Thinking about fix and the special TypeError||become behavior happening
> after the trap call, I think it would make sense that for the particular
> "fix" value, Proxy.trap would call the trap and do the TypeError||become
> behavior. I may be wrong, but I think that if a user calls
> Proxy.trap("fix"), s/he expects the proxy to be fixed afterward.
Following your design of allowing proxy users to explicitly call all traps,
rather than special-casing "fix", an alternative could be to introduce a
Proxy.fix(proxy, pdmap) method that expects a property descriptor map and
fixes the proxy, so that regular fixing would become expressible as
|Proxy.fix(proxy, Proxy.trap(proxy,"fix",[]))|. IIRC, an early version of
the tracemonkey Proxy API had a method similar to Proxy.fix just for the
sake of testing the fix trap, since it didn't support Object.freeze yet.
But again, I would hope that an implementation that supports both
Object.freeze + proxies just supports freezing proxies via the fix() trap as
per the draft spec. I don't see the need for such an implementation to
additionally provide an explicit mechanism like Proxy.fix.
Cheers,
Tom
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
