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

[Mark S. Miller]

On Tue, Sep 6, 2011 at 8:08 AM, Tom Van Cutsem <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.



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

-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110906/038b8bb6/attachment.html>