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

Tom Van Cutsem tomvc.be at gmail.com
Wed Sep 7 06:38:46 PDT 2011


2011/9/6 Mark S. Miller <erights at google.com>

> On Tue, Sep 6, 2011 at 8:08 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>
>> [...]
>> 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.
>

Ok, that rules out this design.


> 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
>>
>> [...]
>>
>> 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.
>

That would probably also allow Object.prototype.toString.call(proxy) to
return, e.g. [object Array], which is another outstanding issue.

I can see this working for Object and Array. Functions are covered by
function proxies. Do we need to consider other primitives?

I still don't see how it would work out for NodeList or other host objects.
Then again, I don't know whether there is a use case that requires this.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110907/f3abcbcb/attachment.html>


More information about the es-discuss mailing list