2011/4/15 Sean Eagan <[email protected]>
> >> 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?
>
I don't think the traps take that many arguments that they merit a
keyword-arguments API.
>
> > 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.
>
The cached getPrototypeOf trap behavior falls prone to the same source of
confusion that caused us to steer away from defining call and construct as
separate traps (cf. the other discussion thread on the uniform proxy API).
I agree with David that the use cases of shared proxy handlers are not
sufficiently explored to merit the addition of customizable "internal proxy
state".
Cheers,
Tom
>
> > 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
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
