[Harmony proxies][Terminology] "fixed" state of a proxy

David Bruant bruant at enseirb-matmeca.fr
Sun Mar 13 13:42:32 PDT 2011


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".

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 suggestto renamethe
>> 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
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110313/7b07aa03/attachment-0001.html>


More information about the es-discuss mailing list