Sept 19 TC39 Meeting Notes

Tom Van Cutsem at
Fri Sep 28 09:28:55 PDT 2012

Hi David,

replies in-line below:

2012/9/28 David Bruant <bruant.d at>

>  Thanks Rick for the notes (and everyone who contributed, I see several
> colors)
> Le 28/09/2012 03:00, Rick Waldron a écrit :
> # Proxy
> (Presented by Tom Van Cutsem, Free University of Brussels)
>  ## Revokable Proxies
>  (...)
>  Question as to whether we really need two kinds of proxies.
> BE: yes, non-revokable proxies have less trap overhead (no null-check)
> I think it's possible to implement both without any overhead.
> TVC suggested below that a revoked proxy is equivalent to a proxy with all
> traps unconditionally throwing; well, a proxy, when revoke could drop its
> target and change its handler on revokation.
> A proxy can be modelled as {target, handler}. Both handler and target are
> set at proxy creation and can't be changed arbitrarily by JS code. We can
> model revocation as a capability that enables to change in one operation
> both target to null and handler to a built-in handler which throws on any
> operation. (it remains impossible to change target and handler arbitrarily
> in JS code)
> Modeled and implemented this way, there is no need for a null check. When
> trapping, the revoked target (null) is passed to the handler trap, which
> doesn't care since it throws regardless of the target value.
> In that model, both type of proxies are just the same type and are as
> efficient. No need for a null check before trapping. Just trap with the
> current value and only provide to JS-land the capability to change the
> target (only to a null value) through revokation.

I think you're right. We might actually use this to our advantage to
specify revokable proxies in a modular, non-intrusive way. That is, rather
than specify revokable proxies by explicitly including a null-check in all
of the algorithms for proxies, we could also specify that the revoke()
function, when called, replaces its proxy's [[Handler]] with a special
built-in handler that throws a TypeError on all traps. Implementors would
still be free to implement it another way.

Allen, what do you think?

>  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.

>  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. I think symbols are closer
to objects: they have an unforgeable identity. Strings don't have that,
objects do.

>  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! ;-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list