Deno 1.14
deno.com
Deno 1.14
1–10 of 111 posts
Re: Deno 1.14
#2Only tangentially related, but what's the point of a static class block? What problem does it solve that's not covered by either the class constructor or a static const? Doesn't it introduce a weird (stateful!) computation that's hard to reason about?
There's probably a use-case I'm missing, because intuitively I'd automatically classify it as bad a practice.
Re: Deno 1.14
#3Funny, I was just looking into whether I could add a Deno config file to my project. Nice to know this was just made possible!
Re: Deno 1.14
#4Only tangentially related, but what's the point of a static class block? What problem does it solve that's not covered by either the class constructor or a static const? Doesn't it introduce a weird (stateful!) computation that's hard to reason about? There's probably a use-case I'm missing, because intuitively I'd automatically classify it as bad a practice.
Modifying class static private properties
Re: Deno 1.14
#5Funny, I was just looking into whether I could add a Deno config file to my project. Nice to know this was just made possible!
Can you share a bit on the use case, i.e. what do you need configured?
Personally, I find Deno's "zero config" approach appealing, although I do have to fight the linter's "ban-types" rule occasionally since suggested type replacements are not equivalent.
Re: Deno 1.14
#6Only tangentially related, but what's the point of a static class block? What problem does it solve that's not covered by either the class constructor or a static const? Doesn't it introduce a weird (stateful!) computation that's hard to reason about? There's probably a use-case I'm missing, because intuitively I'd automatically classify it as bad a practice.
It might be helpful if you have a "registry" of classes. The classes can self-register statically, rather than you having to add separate code which registers the just-declared class.
It seems like a minor convenience, but it might play well with inheritance or mixin classes?
Re: Deno 1.14
#7Funny, I was just looking into whether I could add a Deno config file to my project. Nice to know this was just made possible!
Can you share a bit on the use case, i.e. what do you need configured? Personally, I find Deno's "zero config" approach appealing, although I do have to fight the linter's "ban-types" rule occasionally since suggested type replacements are not equivalent.
Please open an issue on denoland/deno_lint with examples so we can make the diagnostic messages more useful.
Re: Deno 1.14
#8Only tangentially related, but what's the point of a static class block? What problem does it solve that's not covered by either the class constructor or a static const? Doesn't it introduce a weird (stateful!) computation that's hard to reason about? There's probably a use-case I'm missing, because intuitively I'd automatically classify it as bad a practice.
> Doesn't it introduce a weird (stateful!) computation that's hard to reason about?
Yes and no. For example, maybe you want to initialise a temporary directory on the filesystem for writing files to, for some caching mechanism. The pointer to the cache directory (maybe a const x = {}) can exist anywhere, but spinning up the directory itself in the static class block ensures that it's set up once and only once for all instances of the class. So, any instances get to reuse the directory without worrying about checking for initialisation first.
Just another tool in the toolbox, best evaluated on a case-by-case basis
Re: Deno 1.14
#9Funny, I was just looking into whether I could add a Deno config file to my project. Nice to know this was just made possible!
Can you share a bit on the use case, i.e. what do you need configured? Personally, I find Deno's "zero config" approach appealing, although I do have to fight the linter's "ban-types" rule occasionally since suggested type replacements are not equivalent.
> Personally, I find Deno's "zero config" approach appealing, although I do have to fight the linter's "ban-types" rule occasionally since suggested type replacements are not equivalent.
Precisely this. I'm compiling TS using `Deno.emit()`, which can be directly configured, but it would be nice to just configure Deno's linting/compiling behavior at the project level so that the same issues don't appear in VS Code with the Deno extension.
Re: Deno 1.14
#10How it is the zero-copy ArrayBuffer transfer function implemented?