July TC39 meeting notes, day 1

David Bruant david.bruant at labri.fr
Sat Aug 13 17:26:24 PDT 2011


Le 12/08/2011 16:55, Tom Van Cutsem a écrit :
> 2011/8/12 Andreas Rossberg <rossberg at google.com
> <mailto:rossberg at google.com>>
>
>     On 12 August 2011 13:53, Tom Van Cutsem <tomvc.be at gmail.com
>     <mailto:tomvc.be at gmail.com>> wrote:
>     > I think I found a compelling and easy-to-understand
>     > rule for determining whether or not a trap needs access to
>     proxy/receiver:
>     > if the trap deals with inherited properties, it needs access to
>     |proxy|.
>
>     [...]
>
>     Although that rule seems fairly simple, I still find a half/half
>     situation unnecessarily confusing and error-prone. I would strongly
>     vote for making the API consistent. That is, either equip all methods
>     with a proxy argument (preferably as first), or none.
>
>
> Despite the simple rule, I too would prefer passing |proxy| to all
> traps (but not as first argument), even though, as Brendan noted, it's
> not strictly necessary and consistency in one dimension sacrifices
> consistency in another. It would be good to hear more opinions on this.
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.
"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.
-----
var b = true;

function f(){
  if (b)
    f1();
  else
    f2();
}

b = Math.random() < 0.5;
-----
i can provide f as a call trap, it is not more "fixed" than any other
trap provided in the handler.

As another argument in favor of putting call and construct in the
handler, there is the meta-handler-based membrane. With the current
handlerMaker, the resulting object can still be called and constructed.
I just gave above a solution for that issue, but having call and
construct in the handler would allow the generic solution to work
without extra effort.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110814/3a8605b9/attachment.html>


More information about the es-discuss mailing list