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

[David Bruant]

Le 07/09/2011 15:38, Tom Van Cutsem a écrit :
> 2011/9/6 Mark S. Miller <erights at google.com <mailto:erights at google.com>>
>
>     On Tue, Sep 6, 2011 at 8:08 AM, Tom Van Cutsem <tomvc.be at gmail.com
>     <mailto: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.
Emulating the DOM, probably. It would still be possible to have 
non-extensible trapping proxies, but not turn the proxy into a native 
DOM Document/Node/Element/HTMLElement/DocumentFragment, etc... This 
could create some bad performance penalty for DOM Traversers [1] for 
instance (or querySelectorAll). Would it even be possible to have an 
"hybrid" DOM tree with native DOM Node and emulated DOM Node?

Also, one very annoying aspect of the DOM is the inability to use what 
could be expected to be a constructor as such. Both "Document()" and 
"new Document()" throw a TypeError (FF6 and latest Chrome). This 
complicates asking an engine to turn a proxy into a given native DOM 
host object by passing a "constructor" since apparently, not all host 
objects have some.

David

[1] http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110907/97db27ff/attachment.html>