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