David,
You raise valid points, but I can't help but think that many of these issues
are no longer related to proxies per-se, but more to "principles on how to
develop an OO framework / hierarchy in Javascript". The particular set-up we
are discussing with per-proxy handler objects that encapsulate
Le 20/04/2011 17:09, Tom Van Cutsem a écrit :
>
> 2011/4/18 Sean Eagan mailto:seaneag...@gmail.com>>
>
>
> Existing default handler useless to shared handlers:
> ==
>
> The existing Proxy.Handler.prototype and all of its trap
Le 19/04/2011 21:33, Sean Eagan a écrit :
> On Mon, Apr 18, 2011 at 7:38 PM, David Bruant wrote:
>>> Thus, it seems to me that storing
>>> anything in handlers besides existing traps is likely to cause future
>>> headaches, and should be avoided.
>> That's an excellent point. It sounds to be a saf
>
> As a side note, I'd like to say that, in my opinion, Proxy.Handler is a
> misleading name. It seems to imply that all handlers must/should/had
> better be a forwarding handler. I agree that it is certainly (one of)
> the most important use case, nevertheless, it is a restricting view of
> proxi
>
Whether it's the trap or its return value that is cached, the confusion
remains the same. The current API makes it crystal-clear to the programmer
that the prototype is to be calculated ahead-of-time and can't be changed. I
don't see why this API needs to change.
> > I
On Mon, Apr 18, 2011 at 7:38 PM, David Bruant wrote:
>> Thus, it seems to me that storing
>> anything in handlers besides existing traps is likely to cause future
>> headaches, and should be avoided.
> That's an excellent point. It sounds to be a safe idea to consider the
> handler as a namespace
Le 18/04/2011 21:55, Sean Eagan a écrit :
> Storing proxy instance state directly within handlers:
> ==
>
> Trap namespace pollution:
>
> The default handler, Proxy.Handler, stores proxy instance state
> directly in each handler's "target"
nce the prototype argument would probably want to be removed
from Proxy.create / Proxy.createFunction, which would involve breaking
existing code.
> I agree with David that the use cases of shared proxy handlers are not
> sufficiently explored to merit the addition of customizable "internal
he 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&#
>> 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 pr
Le 13/04/2011 23:24, Sean Eagan a écrit :
> One way to get truly shared proxy handlers
Do we want it?
In my previous thread, I discussed shared handlers, but more from a
proxy writer experience point of view, not with the idea of having
something specified toward it. The topic had already b
One way to get truly shared proxy handlers would be to allow proxies
to have some internal instance "state" that gets passed to each trap,
just like objects have internal instance state ( [[Prototype]],
[[Class]], [[Extensible]] etc) that gets "passed" to their "traps&quo
12 matches
Mail list logo
