Minimal proposal spec

[Jack-Works]

close #8

[acutmore]

Only having the isRevoked getter and not a way to listen for the revoke call seems like it would add a delay to when the target and handler references are dropped allowing them to be collected?

[ajvincent]

I think having Proxy.revocable() not always return {proxy, revoke} is something we can not ask for. Though it may seem weird, I can foresee someone out there wanting to still revoke an individual proxy, while letting hundreds of others live. Plus, it's a change in what the function actually returns from a generic dictionary to a Proxy.

So the algorithm at 1.3 step 3b has to go, and the "Else" branch at 1.4 has to be unconditionally run, I think.

[ajvincent]

Only having the isRevoked getter and not a way to listen for the revoke call seems like it would add a delay to when the target and handler references are dropped allowing them to be collected?

Observation was dropped / deferred to another time, per #4. As for why, the brief explanation at the bottom of our README gives the rationale.

[Jack-Works]

The current semantics allows the engine to GC all targets & handlers of the proxy.

I think having Proxy.revocable() not always return {proxy, revoke} is something we can not ask for.

What about changing Proxy.revocable to return { proxy: T, revoke?: Function }? I prefer adding this functionality to the Proxy.revocable instead of new Proxy because it has better semantics.

[Jack-Works]

Though it may seem weird, I can foresee someone out there wanting to still revoke an individual proxy, while letting hundreds of others live.

Oh... This is definitely reasonable. So the correct choice is: accept it on both Proxy.revocable and new Proxy (as 3rd argument)

[ajvincent]

The current semantics allows the engine to GC all targets & handlers of the proxy.

I think having Proxy.revocable() not always return {proxy, revoke} is something we can not ask for.

What about changing Proxy.revocable to return { proxy: T, revoke?: Function }? I prefer adding this functionality to the Proxy.revocable instead of new Proxy because it has better semantics.

This proposal is definitely aiming at Proxy.revocable, and considering new Proxy in #6.

[Jack-Works]

spec updated.

[ajvincent]

I still have a concern about directly referencing AbortController as the mass-revocation signal basis.

[Jack-Works]

Maybe we can follow https://github.com/tc39/proposal-cancellation/issues/31 as our foundation.

[ajvincent]

There's a conflict. Can you please update this PR to account for that?

[Jack-Works]

@ajvincent done