5 ms·
> navigator.locks.request("my_resource", async (lock) => { This would be so much more readable with `using` { using lock = navigator.lock('my_resource')
by unilynx 2y ago
> navigator.locks.request("my_resource", async (lock) => {
This would be so much more readable with `using`
{
using lock = navigator.lock('my_resource');
await do_something();
await do_something_else();
}
(https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen...)
- sureIy 2y agoYou can probably wrap it to have that API
- n2d4 2y agoSadly it needs a language feature that doesn't exist yet
- wruza 2y agos/yet/thankfully/. We don’t need it cause it solves no real problem and the solution is loaded with implicit complexity.
- unilynx 2y ago'using' fixes having to do cleanup in a finally {} handler, which you can a) forget, and b) often messes up scoping of variables as you need to move them outside the 'try' block.
- wruza 2y agoIt also creates additional finalization semantics for a using-ed value. Which has all sorts of implications. lock.do(async (lock) => {work}) is a similar construct - a scope-limited aquisition that requires nothing special. Catch/finally not sharing a scope with try is a repeated mistake, that I surely agree with!
- sureIy 2y agoWhat do you mean? You can definitely already wrap that into a Symbol.dispose-keyed object and use it via `using`
- n2d4 2y ago`using` is not a thing in JS
- sureIy 2y agoUh, you are wrong. It absolutely is a thing and it has been in your browser and Node for longer than a year. https://github.com/nodejs/node/pull/48518 https://github.com/nodejs/node/pull/48518 https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen...
- yoavm 2y agoIt doesn't actually feel more readable to me. I find the idea that the lock declaration sits at the same level as the lock content confusing.
- zeroxfe 2y agoIt's readable if you're familiar with the RAII pattern which is used in languages like C++ and Go.
- saagarjha 2y agoI always felt that pattern was a bit too clever than it was a good design.
- karmarepellent 2y agoMakes me wonder what part of the pattern you think is "too clever"? I think it is fairly easy to reason about when the lock is restricted to the encompassing block and automatically dropped when you leave the block.
- saagarjha 2y agoIt’s kind of a weird design that some of your variables (which you can define anywhere in the scope FWIW) just randomly define a critical section. I strongly prefer languages that do a with lock { // do stuff } design. This could be C++ too to be honest because lambdas exist but RAII is just too common for people to design their locks like this.
- viraptor 2y agoIt's also similar to C#'s "using ...;" without a block. Syntax sugar there rather than RAII, but looks the same.
- zigzag312 2y agoC#'s using can be used without a block. It disposes the resource at the end of a current scope.
- chrisfosterelli 2y agoWhy can't we just `await` the lock call? Edit: Nevermind, release of the lock is automatic when the callback resolves its promise. I get it now.
- KTibow 2y agoIf you really wanted it to be at the top level you could probably turn it into an explicit `release` call using a wrapper and two `Promise` constructors, though that would probably be a bad idea since it could introduce bugs
- pwdisswordfishz 2y agoIf it only weren’t for that crippled "using" syntax. On the other hand, though: const denialOfService = res => void navigator.lock(res); I mean, one might write this just as well with the callback interface, but this is much easier to do accidentally.
- mpweiher 2y agonavigator whileLocked:'my_resource' do:{ :protected | protected doSomething. protected doOtherThing. }
- creativenolo 2y agoSubjectiveness aside on what’s more readable… your proposing a new language feature would be more readable than an API design. To me, the MDN proposal is declarative whereas your proposal is imperative. And with my subjectiveness, JavaScript shines in declarative programming.