>> I think it might be better anyway to switch
>> to a single object argument for all traps so that the order becomes
>> irrelevant, of course the argument names then become relevant, so it's
>> a tradeoff.
Any comments on this idea?
> TC39 seems to be going in the opposite direction (adding a prototype
> argument to createFunction) [2]
The API I proposed could also allow for custom function proxy
prototypes, just using the "getPrototypeOf" trap instead of a
prototype argument.
> I am under the impression that starting here, you're proposing other
> changes to the Proxy API, so at some point, the question will arise too:
> What is the use case you're addressing?
The main use case would be a way to package up all meta behavior
(handler + callTrap + constuctTrap + initialization of internal state
/ prototype used by these traps) so that it can be reused by multiple
proxies. In the API I proposed these are what are returned from
Proxy.Constructor, which is sort of like a meta-constructor (analogous
to meta-class). It could someday lead to an executable spec for
native constructors (Object, Array, etc), but as you mentioned that it
is not nearly as important as application use cases. Also, this
packaging would allow implementations to only store a reference to the
package for each proxy, rather than to each of handler, callTrap,
constructTrap.
> If you merge Proxy.create and Proxy.createFunction, how do you intend to
> distinguish function proxies from "object proxies"?
> I think that the rational behind having two methods is actually to have
> a clear distinction between how both are created so that creation rules
> can be different.
>
With a single API, the distinction would just be that function proxies
have a callTrap.
>> Proxy.Handler = {
>> ...
>> create: function(target) {
> I'm puzzled by the "target" argument name. Are you only addressing the
> forwarding proxy use case?
>
There would be no requirements on the "create" arguments, was just an
example for Proxy.Handler. Sorry, forgot to mention here that I
intended "Proxy.Handler" to replace "Proxy.Handler.prototype" from the
existing API.
> All what you're describing is quite interesting, but I don't think it is
> solving a new use case. I have the impression that besides the
> additional state argument (which could be emulated as state objects in a
> WeakMap indexed on your proxies), all what you're describing could be
> written as a library on top of the current Proxy API.
WeakMaps would work. Built in support though could allow for more
interoperability between use cases, better performance, and simpler
code. Here is hypothetical code to compare that does the same thing
for both strategies...
// existing proxy API using weak maps
let handler = {
states: new WeakMap(),
setState: function(proxy, state) {
this.states.set(proxy, state);
},
getState: function(proxy) {
return this.states.get(proxy);
},
...
getOwnPropertyDescriptor: function(name, proxy) {
var state = this.getState(proxy);
...
},
...
};
let
proxy = Proxy.create(handler, getPrototype(state)),
handler.setState(proxy, state),
functionProxy = Proxy.createFunction(handler, callTrap,
constructTrap, getPrototype(functionState)),
handler.setState(functionProxy, functionState);
// API proposed in this thread
let handler = {
create: function(state) {
return state;
},
...
getPrototypeOf: function ( { state } ) {
return getPrototype(state);
}
...
getOwnPropertyDescriptor: function( {state, name} ) {
...
},
...
};
let
Handler = new Proxy.Constructor(handler),
proxy = new Handler(state),
FunctionHandler = new Proxy.Constructor(handler, callTrap, constructTrap),
functionProxy = new FunctionHandler(functionState);
Weak Maps:
Need to retrieve proxy state in each trap
Need to retrieve state multiple times for derived traps
Boilerplate code in each trap
Slightly higher infinite recursion hazard since you have to use the
proxy reference in order to get the internal state.
Proposed API:
Impossible to forget to initialize the state and prototype, because it
is built into the API.
Impossible for any traps to be called prematurely before state is initialized.
Thanks,
Sean Eagan
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
