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

David Bruant bruant at enseirb-matmeca.fr
Fri Mar 18 03:25:00 PDT 2011


Le 16/03/2011 08:59, Tom Van Cutsem a écrit :
> David,
>
> I agree that Proxy.isProxy (or Object.isProxy) is strictly a better
> name than Proxy.isTrapping.
> I also agree that in developer-facing documentation, using the terms
> "proxy" vs "regular object" instead of "trapping" vs "fixed" proxy is
> better.
I'll change the MDN documentation soon, unless someone has an objection.

> On the other hand, for spec. and implementation purposes, it does make
> sense to have terminology for "an object formerly known as a proxy".
> As Andreas points out, fixed function proxies may still behave
> observably different from regular functions.
>
> Also, there's still the "fix()" trap. Are you suggesting to rename
> this one as well?
no no, I am not. I was just talking about the proxy "state" terminology.

> It doesn't seem necessary to me. One could state that by fixing a
> proxy, the proxy becomes a regular object.
>
> I'll make a note of your Proxy.isProxy suggestion, should this method
> ever be spec'ed.
>
> 2011/3/13 David Bruant <bruant at enseirb-matmeca.fr
> <mailto:bruant at enseirb-matmeca.fr>>
>
>     That's a very interesting point.
>     But there is indeed a subtle difference between call/construct
>     traps and the rest of the handler. These traps are actually more
>     of the "internal property setting" kinds (like the prototype
>     argument in Proxy.create). I think that it is the reason why these
>     things are separated from the handler object; they are more like
>     "direct static setting".
>
>     When reading the semantics of [[Prototype]], [[Call]] and
>     [[Construct]], one can notice that there is no external
>     dependency. The proxy contains references to what has been passed
>     as an argument (and their own internal properties) and uses them
>     without being disturbed.
>     All the other internal method semantics have a dependency on the
>     handler object (the internal method is reified as the handler trap
>     dynamically not as the value at initialisation time). This is one
>     difference.
>
>     Another difference is that the main goal of turning the proxy into
>     an object after preventExtension is to prevent the proxy from
>     breaking invariants. Among these invariants, the fake-object
>     shouldn't be able to be added properties to, so property-adding
>     (defineProperty/set) traps should be shutdown. Another invariant
>     is that two consecutive calls to property introspection traps
>     shouldn't allow you to pretend that properties have been added. So
>     property-introspection traps (all remaining except delete and fix)
>     should be removed.
>     And shutting down some traps wouldn't really make sense without
>     removing them all I think (I do not feel 100% strong on this).
>
>     The way I see it, after the fix trap, the proxy isn't trapping
>     anything. For function proxies, I would consider the case as: what
>     remains is a function with user-defined [[Call]] and [[Construct]]
>     internal methods. It wouldn't actually be very far from what we
>     could expect from a Function.create(call, constr) method which I
>     would see as some sort of equivalent of the Object.create(prototype).
>
>     David
>
>     Le 13/03/2011 21:50, Andreas Gal a écrit :
>>
>>     There is a little twist to this. You can create a proxy that has
>>     separate implementations of [[Call]] and [[Construct]], and by
>>     fixing it, it converts to a regular functions. However, this
>>     "regular" function is different from any other non-host function:
>>     it behaves different w.r.t. to f() and new f(). At the
>>     implementation level this is reflected by the fact that we use a
>>     different internal class for these "function" objects. It also
>>     maintains all the other behaviors of the original proxy [[Call]]
>>     and [[Construct]] hooks, i.e. new f() can return "5". I am not
>>     sure whether this difference warrants talking about fixed
>>     proxies, but I wanted to point it out.
>>
>>     Andreas
>>
>>     On Mar 13, 2011, at 10:08 AM, 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
>>
>
>
>     _______________________________________________
>     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/20110318/f2a871e9/attachment.html>


More information about the es-discuss mailing list