July TC39 meeting notes, day 1
tom at schuster.me
Fri Jul 29 12:18:15 PDT 2011
I am wondering if you discussed the typeof null proposal?
On Thu, Jul 28, 2011 at 9:46 PM, Andreas Rossberg <rossberg at google.com> wrote:
> On 28 July 2011 20:34, David Bruant <david.bruant at labri.fr> wrote:
>> Le 28/07/2011 19:52, Andreas Rossberg a écrit :
>>> On 28 July 2011 10:35, David Bruant <david.bruant at labri.fr> wrote:
>>>> Le 28/07/2011 06:21, Brendan Eich a écrit :
>>>>> == Handler access to proxies ==
>>>>> Proxy handler traps need to receive the proxy as a parameter: first, or
>>>>> Last allows trap implementors to leave |proxy| off. It's also a compatible
>>>>> extension to the proposal and its prototype implementations. Putting |proxy|
>>>>> last may also steer implementors away from touching proxy, reducing the bugs
>>>>> where you infinitely diverge.
>>>>> First is more normal-order (proxy, name) and some find it more
>>>>> aesthetically pleasing.
>>>>> Another alternative: the proxy could be "passed" via a data property on
>>>>> the handler.
>>>> I think we discussed already the idea of "proxy" being passed as a data
>>>> property to the handler and came to the conclusion that it may not be a good
>>>> idea, because it breaks the stratification. If two proxies use the same
>>>> handler as in , then, there is an ambiguity on what the value of this
>>>> property should be.
>>> The solution we discussed is to simply use prototypes. That is, share
>>> handler methods by putting them on a (single) prototype object, and
>>> have per-proxy instances that carry the individual proxy references
>>> (or other per-proxy data, for that matter).
>> This is a pattern that I have seen used by Tom a lot and that I really
>> like too, but you can't force a user to do that.
>> So I assume, you would systematically add a base object and use the
>> argument handler as its prototype?
>> // h is a handler object
>> var p1 = Proxy.create(h);
>> var p2 = Proxy.create(h);
>> When a user does this, what does he want? To use the exact same handler
>> (same object identity)? Or to use the same logic but different internal
>> The solution you discussed seems to assume the latter, but who knows?
>> And how do I implement the former if the proxy spec imposes that the
>> object I pass internally becomes another object?
> I'm not sure I understand what you are asking. The solution I
> mentioned is purely user-side. There is no magic assumed in the proxy
> semantics. If you pass the same handler twice, it will be the same
> handler. If you need proxy-specific state, pass different handlers. If
> you still want some form of code sharing, use prototypal delegation.
>> Now that I think about it, it's a bit weird that the proxy API allows to
>> create several proxies with the same handler (same object identity).
>> Maybe the API could be reworked in order to prevent it? Maybe
>> Proxy.create should return the same proxy object if provided the same
>> handler (p1 === p2, here)?
> I agree that there probably aren't too many useful examples for using
> the same handler. However, I also don't see a good reason for
> disallowing it, nor to require Proxy.create to memoise all handlers.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss