6 ms·

In defense of blocks for local scopes

27 points by jacobr 4y ago

teg4n_ 4y ago
I’ll just cross my fingers for do expressions getting adopted. Before then functions work for me and none of the gist convinced me otherwise.
- UncleEntity 4y ago
  Couldn’t you just: /* do */ { const foo = “bar” do_the_stuff(foo) } /* while(JS_sux) */ Typing code on a phone is hard…
  - eyelidlessness 4y ago
    You can even just use `do { … } while (false)` without comments, but neither is an expression. Neither produce a value. The do expression would have similar encapsulation but allow assigning a derived value to a lhs binding, as you could do in a lisp (or Rust [or Swift, or…]).
    - matthews2 4y ago
      > as you could do in a lisp (or Rust [or Swift, or…]) There's also a GCC extension for this! https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html I'm using this for something a bit like Rust's unwrap (but uglier): #define UNWRAP(expr) \ {{ \ auto result_ = (expr); \ if (!result_.present()) panic(); \ result_.disown(); \ }} optional<int> foo(); void bar() { int val = UNWRAP(foo); }
- stkdump 4y ago
  Isn't a do expression the same + ability for the block to return a value? So what if you don't need to return a value?
  - teg4n_ 4y ago
    Don’t return one then?
culturedsystems 4y ago
If your code is sufficiently distinct that block scope is useful, and there's no obvious contextual clue as to why it's distinct (like an if statement), put it in a separate function to explain why it's distinct. The article mentions this argument, but responds with some handwaving about how technically it's valid JS to use an unnamed block statement. I mean, sure, but does that mean it's a good idea?
- spc476 4y ago
  I've used this method in C code. One reason---C89 only allows variable declarations at the top of a block, and if I have a small section of code towards the middle of end of the function with its own variable use, the declaration is separated from the use. By using a new scope, the declaration can be done right where it's used. Yes, it looks a bit weird, but there could be benefits. I also use this in Lua. The benefit there---once the scope is over, the variables declared in the scope become available for garbage collection. In a small function, this isn't that much of a win, but for the top level scope, it probably is. You can see an example of this in my gopher server [1]. Don't let the formatting confuse you, this: local CONF = {} do local conf,err = loadfile(arg[1],"t",CONF) if not conf then io.stderr:write(string.format("%s: %s\n",arg[1],err)) os.exit(exit.CONFIG,true) end -- rest of code end is the same as local CONF = {} do local conf,err = loadfile(arg[1],"t",CONF) if not conf then io.stderr:write(string.format("%s: %s\n",arg[1],err)) os.exit(exit.CONFIG,true) end -- rest of code end The 'do' keyword introduces a new scope (and can be used anywhere to do so). I format it as the former to be more explicit about the CONF variable being defined by the following code block. [1] https://github.com/spc476/port70/blob/master/port70.lua#L41 https://github.com/spc476/port70/blob/master/port70.lua#L41
- spc476 4y ago
  Oh, one other reason to do the new scope instead of a function---you can still use variables in the outer scope that you might otherwise have to pass in to a function.
- ebingdom 4y ago
  > but does that mean it's a good idea? Yes, to me it does. I love when variables have really tight scopes so I don't need to worry about if/how they are used throughout the rest of the program. Locality should be the default, not something that needs to be justified. Creating a function is just unnecessary boilerplate if the code is not going to be reused. Functions are just named blocks with arguments. But if you don't need to name the block and don't need to reuse it with varying arguments, creating a function is just unnecessary. Functional programmers are familiar with a concept called "let", which essentially gives you a way to introduce a variable and introduce a new scope just for that variable. This article is essentially just showing how to do that in JavaScript.
tengbretson 4y ago
How about don't use let or var declarations at all?
- triyambakam 4y ago
  Sounds unreasonable at first, and maybe you're being sarcastic, but I've actually found that trying that as a discipline helps with readability, because each const variable gets a very descriptive name related to the action.
duxup 4y ago
I had no ideas this was an option in JavaScript. Fun read.

27 points by jacobr 4y ago

I’ll just cross my fingers for do expressions getting adopted. Before then functions work for me and none of the gist convinced me otherwise.

UncleEntity 4y ago
Couldn’t you just: /* do */ { const foo = “bar” do_the_stuff(foo) } /* while(JS_sux) */ Typing code on a phone is hard…
- eyelidlessness 4y ago
  You can even just use `do { … } while (false)` without comments, but neither is an expression. Neither produce a value. The do expression would have similar encapsulation but allow assigning a derived value to a lhs binding, as you could do in a lisp (or Rust [or Swift, or…]).
  - matthews2 4y ago
    > as you could do in a lisp (or Rust [or Swift, or…]) There's also a GCC extension for this! https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html I'm using this for something a bit like Rust's unwrap (but uglier): #define UNWRAP(expr) \ {{ \ auto result_ = (expr); \ if (!result_.present()) panic(); \ result_.disown(); \ }} optional<int> foo(); void bar() { int val = UNWRAP(foo); }
stkdump 4y ago
Isn't a do expression the same + ability for the block to return a value? So what if you don't need to return a value?
- teg4n_ 4y ago
  Don’t return one then?

culturedsystems 4y ago

If your code is sufficiently distinct that block scope is useful, and there's no obvious contextual clue as to why it's distinct (like an if statement), put it in a separate function to explain why it's distinct. The article mentions this argument, but responds with some handwaving about how technically it's valid JS to use an unnamed block statement. I mean, sure, but does that mean it's a good idea?

spc476 4y ago
I've used this method in C code. One reason---C89 only allows variable declarations at the top of a block, and if I have a small section of code towards the middle of end of the function with its own variable use, the declaration is separated from the use. By using a new scope, the declaration can be done right where it's used. Yes, it looks a bit weird, but there could be benefits. I also use this in Lua. The benefit there---once the scope is over, the variables declared in the scope become available for garbage collection. In a small function, this isn't that much of a win, but for the top level scope, it probably is. You can see an example of this in my gopher server [1]. Don't let the formatting confuse you, this: local CONF = {} do local conf,err = loadfile(arg[1],"t",CONF) if not conf then io.stderr:write(string.format("%s: %s\n",arg[1],err)) os.exit(exit.CONFIG,true) end -- rest of code end is the same as local CONF = {} do local conf,err = loadfile(arg[1],"t",CONF) if not conf then io.stderr:write(string.format("%s: %s\n",arg[1],err)) os.exit(exit.CONFIG,true) end -- rest of code end The 'do' keyword introduces a new scope (and can be used anywhere to do so). I format it as the former to be more explicit about the CONF variable being defined by the following code block. [1] https://github.com/spc476/port70/blob/master/port70.lua#L41 https://github.com/spc476/port70/blob/master/port70.lua#L41
spc476 4y ago
Oh, one other reason to do the new scope instead of a function---you can still use variables in the outer scope that you might otherwise have to pass in to a function.
ebingdom 4y ago
> but does that mean it's a good idea? Yes, to me it does. I love when variables have really tight scopes so I don't need to worry about if/how they are used throughout the rest of the program. Locality should be the default, not something that needs to be justified. Creating a function is just unnecessary boilerplate if the code is not going to be reused. Functions are just named blocks with arguments. But if you don't need to name the block and don't need to reuse it with varying arguments, creating a function is just unnecessary. Functional programmers are familiar with a concept called "let", which essentially gives you a way to introduce a variable and introduce a new scope just for that variable. This article is essentially just showing how to do that in JavaScript.

tengbretson 4y ago

How about don't use let or var declarations at all?

triyambakam 4y ago
Sounds unreasonable at first, and maybe you're being sarcastic, but I've actually found that trying that as a discipline helps with readability, because each const variable gets a very descriptive name related to the action.

duxup 4y ago

I had no ideas this was an option in JavaScript. Fun read.