Sept 19 TC39 Meeting Notes
bruant.d at gmail.com
Fri Sep 28 10:47:47 PDT 2012
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
>> 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
> 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
> 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"...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss