Le 15/03/2011 18:07, Allen Wirfs-Brock a écrit :
> I think there is something deeper lurking behind this issue. Proxies can be
> used to define objects whose property semantics can be quite different from
> those of native objects. In some situations the built-in Object. reflection
> functions are not going to be flexible enough to reify a mirror model of
> those semantics. If the designers of such proxy-based object abstraction
> want to expose their unique semantics to reflection-based manipulation they
> are is going to have define new reflection functions that are specific to
> their abstraction.
I fully agree..
In the same vein, I was recently thinking about the non-ES5 traps
(getPropertyNames/getPropertyDescriptor). The equivalent Object
reflection functions can be easily implemented for native objects.
However, from a proxy point of view, a native or user-defined
Object.getPropertyNames makes a big difference since the former triggers
the getPropertyNames trap while the latter cannot (and calls the traps
used in the user-defined implementation instead).
> I think we probably need to work through some such scenarios to understand if
> there are any lurking issues. One thing I'm wondering about is whether any
> additional "back-door" access to a proxy's handler will be necessary to cross
> to the meta level. For example, imagine:
>
> OrderedObject.reorder(obj,["prop3","prop2","7","prop12","1"]); //2nd
> argument re property names in their new order
Exactly. I thought about that soon after posting my message too.
Yesterday, I've been working on a prototype in preparation of a
discussion on the proxy proposal open issue (about
normalizing/throwing/doing nothing if traps input/output aren't valid).
While working on it, it has raised some issues with the idea of a "proxy
factory". The baseline of the "problem" is that if you want to create an
OrderedObject, you cannot go for:
function OrderedObject(){}
var oo = new OrderedObject();
It basically comes from ES5.1 13.2.2 [[Construct]] step 1 : "Let obj be
a newly created native ECMAScript object". So if I want to create a
Proxy-based object, my constructor itself has to be a function proxy (to
reify [[Construct]]). So I don't know, there might be things to
investigate in order to discuss factory patterns for proxies. I'll do
that in another thread after releasing my code, it'll be a way to
discuss on something concrete.
Discussing factory patterns may be related to the idea of how to deal
with providing other abstraction-specific reflection functions.
> How does the the reorder function communicate with obj's handler instance
> without also exposing a meta-level API to the application-level. Actually,
> private names might provide a solution.
I am not familiar yet with all other Harmony proposals but private names
might be a solution to the problem you're pointing and modules might
offer an opportunity to help out with factory patterns.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
