[Harmony Proxies] Non-extensible, sealed and frozen Proxies

[David Bruant]

Le 06/09/2011 18:15, Mark S. Miller a écrit :
> On Tue, Sep 6, 2011 at 8:08 AM, Tom Van Cutsem <tomvc.be at gmail.com 
> <mailto:tomvc.be at gmail.com>> wrote:
> [...]
>
>
>         Regardless, it's a good thing to provide the choice. Regarding
>         the open
>         issue ("do we default to Object.create or do we want to allow
>         for the
>         possibility of Array.create etc.?"), I think that the choice
>         should be
>         given to create any sort of object (why not host objects such as
>         NodeList?). One question would be: how could this (easily) be
>         achieved?
>
>
>     I've been thinking about a couple of ways, but there remain open
>     issues:
>
>     1) Have fix() not just return a property descriptor map, but a
>     tuple of [constructor, property descriptor map]. To create the
>     instance it needs to become, the proxy invokes the returned
>     constructor's "create" method with as first argument the proxy's
>     prototype and as second argument the prop. desc. map.
>
>     For example:
>
>     fix: function(operation) {
>       // I want to become an array
>       return [Array, { ... } ];
>     }
>
>
> Array.isArray and other [[Class]] checks (e.g., the Flanagan device of 
> using ({}).toString.call) need to give stable answers. Especially 
> because they currently always do give stable answers.
Indeed, so if a [[Class]] is given to a proxy, it has to be done at 
proxy creation so that the proxy and its fixed version are stable 
regarding [[Class]] checks.

>
>     2) Add the constructor to use upon fixing as an additional
>     argument to Proxy.create{Function}, e.g.:
>
>     var p = Proxy.create(handler, proto, Array);
>     // fix() trap will use Array.create
>
>
>     The thing is: we can't let proxy authors just pass any arbitrary
>     object as the "constructor", e.g.
>
>     var myconstructor = { create: function(proto, props) { ... } };
>     Proxy.create(handler, proto, myconstructor);
>
>     This is because myconstructor could return arbitrary live objects
>     from its call to "create", and the "become" trick with proxies
>     really only works when the proxy can transplant its brains with a
>     newborn object.
>
>     We could state that the "constructor" argument must be equal to
>     Object, Array, and perhaps a handful of other primitive
>     constructors, but that would probably rule out NodeList. How can
>     we get some guarantee that a function is effectively going to
>     produce and return a newborn object?
>
>
> How about we adapt ideas from the "<|" proposal?
This proposal is only about initializing the prototype. I don't see what 
can be adapted to work on [[Class]].


> Proxy.create already takes a proto argument. The third argument could 
> say whether the [[Class]] of the proxy should be "Object" or should be 
> the same as that proto. No constructors.
The notion of "same as the proto" is ambiguous. Do you mean that 
Proxy.create should guess which [[Class]] should be provided based on 
the prototype object?
If I use an object which inherits from Array.prototype, can I still be 
considered as an Array? If there is a [[Class]] A with usually a 
prototype Pa and a [[Class]] B with Pb which inherits from Pa. Can I 
still create an A object with Pb as prototype?

Passing a string and doing consistency checks sounds like a more 
flexible idea.

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