July TC39 meeting notes, day 1

Kevin Reid kpreid at google.com
Fri Aug 12 08:21:41 PDT 2011

On Fri, Aug 12, 2011 at 07:51, Tom Van Cutsem <tomvc.be at gmail.com> wrote:

> 2011/8/12 David Bruant <david.bruant at labri.fr>
>> Regarding [[prototype]], handler.prototype could be just a initialzation
>> value for a copy of the handler, or handler.prototype could be imposed to be
>> a non-configurable, non-writable data property (TypeError if not the case)
>> which will not require to do a handler copy.
> handler.call and handler.construct would have the rules that callTrap and
>> constructTrap have. And typeof Proxy.create(handler) === 'function' <=>
>> typeof handler.call === 'function' (to fit the ES5.1 definition of a
>> function)
> I see your point but still prefer the current API. |Proxy.create(handler,
> proto)| makes it much clearer that |proto| is intended to be fixed at
> creation time than requiring |handler| to define a non-writable data
> property named "prototype".

This reminds me of what I did in my revision of the E proxy API. If it were
to be the case that the proxy is completely defined by a single handler,
then it would be (less im)plausible to have it be the case that

  Proxy.create(handler) === Proxy.create(handler)

That is, a proxy's *identity* is fully specified by its parameters, the
handler. In the E context this has benefits for our equality semantics and
garbage collection. If this were the case in JavaScript, it would mean that
traps would never need a proxy parameter, because Proxy.create(this) would
substitute for it. (The handler methods in E indeed don't get the proxy as a

You probably don't want to do this, but the observation was interesting to
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110812/6728e4cb/attachment-0001.html>

More information about the es-discuss mailing list