July TC39 meeting notes, day 1

Tom Van Cutsem tomvc.be at gmail.com
Mon Aug 15 01:49:59 PDT 2011

Hi David,

2011/8/14 David Bruant <david.bruant at labri.fr>

> We have identified that |proxy| could be used to retrieve the prototype.
> What other "useful" information could be retrieved from |proxy|?
> Its [[Prototype]], its [[Class]], its identity (as |this| for
> getters/setters in get/set traps and as WeakMap key, however this has never
> had a lot of support on es-discuss)?
> [[call]] would be accessible via proxy() or proxy.call()
> [[construct]] would be accessible via new proxy()
> All other internal things seem accessible via the handler (|this| from
> within a handler method context).
> Maybe that there is another dimension of inconsistency which is that
> internal properties and methods can be accessed via two things: the handler
> and the proxy.

I really would not call this an inconsistency. This is really a consequence
of the original design, i.e. the fact that we separate proxy from handler:
that introduces an "application-level" entry point (the proxy), and a
"meta-level" entry point (the handler).

> "two things"... rather than one (the handler) as it was originally.
> Hence my previous e-mail about bringing everything back to the handler
> (prototype, call, construct, etc.)
> Also, it's a bit strange that all traps can be changed dynamically while
> call and construct can't. Well, that's not entirely true: call and construct
> could contain some context in a closure that could change their behavior
> over time.

Your arguments to put |call| and |construct| in the handler are reasonable.
I think that can be done. I recall we decided against it earlier, as it
makes the |handler| reusable across both object and function proxies (they
have the exact same API). However, passing a |handler| with call and
construct traps to an object proxy should be fine.

There would be some consequences though: handler functions are currently
"methods" that are invoked with |this| bound to the handler. Not so with the
call and construct trap (which are thought of as functions and have |this|
bound to undefined). Also, fixing a function proxy requires a change: the
fix() trap should then also return a fixed call and construct trap to use,
in addition to the property map (cf. an earlier proposal: <
http://wiki.ecmascript.org/doku.php?id=strawman:uniform_proxies>). That is a
pity because now the fix() trap is no longer uniform across object/function
proxies. From what I hear from VM implementors, the current distinction
between object/function proxies aligns well with the fixing process.

As for [[Prototype]], [[Class]], identity: I much prefer our current design
guideline, which is that any information that is supposed to be stable/fixed
is better passed as a separate argument to Proxy.create{Function}, rather
than either being queried once from the handler, or requiring the handler to
provide it via a non-writable, non-configurable data property. Passing
|proxy| as an argument to at least the inheritance-related traps seems to
cover all of the use cases we came up with thus far.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110815/ccc0737d/attachment.html>

More information about the es-discuss mailing list