Sept 19 TC39 Meeting Notes

[David Bruant]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120928/d125f691/attachment.html>