On Mar 13, 2011, at 3:42 PM, David Bruant wrote:
> I personnally don't have any strong conviction on the matter (which object
> should carry the function if any). But as I wanted to get rid of a part of
> the terminology that had been used in a method name
> (http://wiki.ecmascript.org/doku.php?id=harmony:proxies#detecting_proxy_objects)
> I just thought it would be fair to mention it and propose a solution to it.
> There is no emergency though. In the proposal is written "The current
> consensus is not to provide this method as it directly breaks “transparent”
> virtualization of objects".
Right, Proxy.isTrapping is not spec'ed, and not prototype-implemented in
Firefox 4.
But the minor terminology issue remains (see Andreas's followup). Would be
great to hear from Tom Van Cutsem on this.
/be
>
> David
>
> Le 13/03/2011 21:32, Brendan Eich a écrit :
>>
>> I buy it.
>>
>> I also cringe a little at Array.isArray, and therefore at Proxy.isProxy, in
>> the pre-modules world ES5 and the proxies proposal inhabit. These seem like
>> tautological predicates, and Object.isArray is prettier and more fitting in
>> my view. But this is a tiny nit to pick. If you buy it, then Object.isProxy
>> would be the predicate.
>>
>> OTOH, with modules we would *not* put isProxy on poor old Object, and one
>> would want isProxy to be an export, along with create, createFunction,
>> Handler, etc., from the standard Proxy module. So at this point I don't
>> propose Object.isProxy.
>>
>> Whee, naming.
>>
>> /be
>>
>> On Mar 13, 2011, at 12:08 PM, David Bruant wrote:
>>
>>> Hi,
>>>
>>> I would like to discuss the terminology of the proposal and the two states
>>> of a proxy: trapping or fixed.
>>> In order to discuss, here is a little example:
>>> ---------------------------------
>>> var o = {};
>>> var p = Proxy.create( forwardingHandler(o) );
>>> p.a = 1;
>>> o.b = 2;
>>> p.c = 3;
>>> o.d = 4;
>>> /* For all x in [a,b,c,d], we have (p[x] === o[x]) and (p.hasOwnProperty(x)
>>> iff o.hasOwnProperty(x)) */
>>>
>>> Object.preventExtension(p); // The "proxy" becomes "fixed"
>>>
>>> delete o.a;
>>> delete p.b;
>>> // o is like {b:2, c:3, d:4} while p is like {a:1, c:3, d:4}
>>> // o and p have lost "synchronicity". p is an object with its own
>>> independent life.
>>> ----------------------------------
>>>
>>> After the Object.preventExtension|seal|freeze call, p isn't a proxy
>>> anymore. It becomes a regular object. None of what used to be p's traps
>>> when it /was/ a proxy is going to be called anymore through p
>>> surface-syntax iteraction. After the call to a succeeding (non-throwing)
>>> fix trap, what we have falls under the definition of an Object as known in
>>> ES5 (and previously). Another way to put it is that there is no way for an
>>> external program to distinguish if p is a proxy or an object (unless this
>>> external program had overriden Proxy.create beforehand).
>>>
>>> The way I see it, a proxy is trapping and that's it. What is "fixed" is an
>>> object, because the proxy has lost all its "magic" (and cannot get it back
>>> by design).
>>>
>>> In my opinion, we should stop talking of proxies as "fixed" and stop using
>>> this terminology because it may cause confusion.
>>> If there is an agreement on this, I'd suggest to rename the
>>> Proxy.isTrapping method as Proxy.isProxy since as I understand it, saying
>>> that a proxy is trapping is a tautology.
>>>
>>> What's your opinion?
>>>
>>> David
>>> _______________________________________________
>>> es-discuss mailing list
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
