Le 28/09/2012 18:28, Tom Van Cutsem a écrit : > > >> Discussion about whether revokable proxies introduce new ways for >> interceptable operations to behave. >> >> WH: Not sure about this as a feature, w/r to future hostility… >> - eg. if "===" would trap to the handler how does this work with >> that? >> >> MM: trapping "===" would be a significant change on its own, >> independent of revokable proxies >> >> TVC: The only type test that is affected is typeof: once the >> proxy is revoked, it drops references to its target and its >> handler, so it can no longer forward the typeof test to its target >> >> BE: It remembers "function" or "object" >> TVC: right > Arguably, a revoked proxy could throw on === or typeof too. > It's already allowed to arbitrarily throw on [[Get]], [[Put]], > 'in', for-in/of loops, Object.getPrototypeOf, etc. It's not that > big of a stretch to throw on typeof or === even though these > aren't trappable. > Unconditionally trapping on any operation on the object is > future-proof. > > > I don't think it would be a good idea to have === and typeof throw on > revokable proxies. First, it breaks the simple story of "a revoked > proxy is just a proxy with a handler that throws". Second, let's not > forget that the reason that === and typeof aren't trapped in the first > place is so proxies wouldn't influence their behavior! > > For typeof it might still be reasonable, as the result of that > operator really depends on some state of the proxy target, which the > revoked proxy must remember separately. But '===' tests identity, > which is (and remains) a property of the revoked proxy itself. This > operator doesn't need the target to produce its result. This point started with an "what if typeof/=== is trappable?". If it's sure that it never becomes trappable, everything's good.
>> WH: unique vs private names? >> STH: The primary purpose of Names is to avoid name clash and >> non-forgeable. Uniques should be reflected, private: not. >> >> WH: What makes them non-forgeable >> >> STH: They are objects > I think it was Tom who suggested in a post that symbols (I'll do > my best to use the new terminology!) are more non-forgeable > strings than non-forgeable objects. Symbols should not be > proxyable. Their only important attribute is their identity, so > proxying them would be absurd. > I think it should be considered to have symboles typeof to be > "string" instead of "object", or maybe something completely new, > but for sure, they are not objects. > > > I agree that proxying a symbol is of little value, but I didn't say > that symbols are closer to strings than to objects. sorry for the misquote :-s >> >> AWB: Not clear how using a built-in WeakSet will protect, what if >> it's been redefined? Are WeakSet methods non-writable? >> TVC: we need to specify that the proxy calls the >> original/intrinsic WeakSet.prototype.get method. > Typof. I think you meant WeakSet.prototype.has (WeakSets have no > "get"). > > > Indeed. It should be "has". > > Note that you made a typo in the word "Typof". A meta-typo! ;-) :-) "typof". My fingers are so used to "typeof"... David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
