Replies: 3 comments 6 replies
-
Note, my goal here is to get something into the design principles document, and then follow up from there with proposals to change all relevant other specifications; this isn't a small, quick, self-contained question. |
Beta Was this translation helpful? Give feedback.
-
My current thinking is web platform specs should not do any work in this area until there is parity between async and sync dispose. Having only a random subset of web objects (those with sync disposal) be usable with this new syntax is something I'd like to avoid on the web platform. And having to push the spec/implementation/tests ecosystem through an adoption curve twice, once for sync and once for async, is not something I think the community should spend time on. (Certainly it's something I'll advise Chromium spec and implementation engineers against spending time on.) |
Beta Was this translation helpful? Give feedback.
-
I wonder if this syntax works for https://github.com/fserb/canvas2D/blob/master/spec/layers.md (proposed at whatwg/html#8476). Note that you need some kind of nesting support. |
Beta Was this translation helpful? Give feedback.
-
Wotcher TAG!
The JavaScript explicit resource management proposal by Microsoft's @rbuckton, at Stage 3 in TC39, defines a new protocol with a method called
[Symbol.dispose]
for resource cleanup. There is a nice syntaxusing resource = expr;
which callsresource[Symbol.dispose]()
at the end of the lexical scope--analogous to C++ RAII, Godefer
, Pythonwith
, etc.I'm filing this issue not to ask for a TAG review of that proposal (this could be done separately) but to start the discussion about how Web Platform APIs should use this new protocol. Many of the motivating use cases are for server environments, but many web APIs may also tie into this protocol--one idea described here.
Another place we're discussing this topic is whatwg/html#8557 . Note the question raised there about how cancellation and disposal should relate. In some mechanical sense, the APIs are dual of each other--for each void-returning API that takes an AbortSignal as a parameter, it would be equivalently expressive for that API to return an object representing the ongoing operation which could instead be disposed to unsubscribe/cancel. However, in many other programming environments, the semantics of cancellation and disposal are very different; for that reason, the integration proposed in the JS proposal readme does not mention cancellation.
It would be ideal if the TAG design principles contained clear guidelines to be used across the web platform to explain the appropriate way to design APIs using Symbol.dispose and/or AbortSignal.
Beta Was this translation helpful? Give feedback.
All reactions