Le 07/09/2011 15:38, Tom Van Cutsem a écrit :
2011/9/6 Mark S. Miller <[email protected] <mailto:[email protected]>>
On Tue, Sep 6, 2011 at 8:08 AM, Tom Van Cutsem <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
