3 ms·

I'm surprised the author hadn't heard of void. There was a time when using it in links (aka `javascript:void(0)`) was very common. Also yeah javascript has lab

I'm surprised the author hadn't heard of void. There was a time when using it in links (aka `javascript:void(0)`) was very common. Also yeah javascript has labels but using them is usually a bad idea. While they may seem useful they can be harder to reason about in all but the simplest code. You're almost always better off restructuring your code instead of using labels.

tgb 9y ago
How did the void(0) thing work in links? I remember being frustrated by it when I couldn't see where the link would take me, but never understood what was going on.
- k__ 9y ago
  these links have an onclick handler. If the handler goes missing or fails, this construct will prevent the link from doing what it usually would. But using a button is better in such cases...
- et-al 9y ago
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/void https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Back then, you'd use it with the `href` attribute to prevent the link from going anywhere (it would return `undefined`), then call a function with the `onclick` attribute. E.g. <a href="javascript:void(0)" onclick="clickHandler()">Click me</a>
- ChrisSD 9y ago
  Basically it defers to a javascript function instead of using the web's normal way of linking. An example of such a link would be: <a href="javascript:void(0)" onclick="dostuff()">Click me</a> href="javascript:void(0)" basically tells the browser to do nothing when a link is clicked. It's like returning false from an event listener. onclick="dostuff()" will then listen for clicks and call the `dostuff` function to update the page or load a new one. Nowadays it's considered bad practice and to be honest it wasn't exactly good practice in those days but it was very commonly used.
pqh 9y ago
Use case for labelled breaks: collision detection in video game, where anything colliding with anything else ends the game, resets a counter, spawns Godzilla, who knows. With labels, you can break out of the top loop very efficiently.
- deleted 9y ago
  [deleted]
- throwanem 9y ago
  You can't efficiently get back into it, though, which can be a problem for a game's event loop. If you wrap it in a function, you can return from that function anywhere inside the loop, and let its caller handle whatever state change incurred the exit and then restart the loop, if it wants, by calling the function again. On the other hand, if the event loop's job also includes rendering the game's UI, then leaving it by any means will freeze the display until it's restarted. That's probably bad too, although I suppose in theory it could be turned into a game mechanic. Absent that, this technique might make more sense in a case where you're running the exitable loop in question on a secondary thread (i.e. a worker), and doing things with it which can be safely interrupted - maybe changing levels or something, where the player isn't expecting to do anything during a UI transition, and you need to await the arrival of some resources over the network and then set up the game state before restarting the event loop to resume normal play? I don't know, that's a bit contrived and probably flawed in a critical way, but I think it makes the same basic sense as offloading heavy and necessarily synchronous work to a worker thread does in general.
eridius 9y ago
It used to be fashionable to use `void 0` for undefined values, both because it's shorter and because it used to be the case that you could actually redefine `undefined` to have some arbitrary value.

tgb 9y ago

How did the void(0) thing work in links? I remember being frustrated by it when I couldn't see where the link would take me, but never understood what was going on.

k__ 9y ago
these links have an onclick handler. If the handler goes missing or fails, this construct will prevent the link from doing what it usually would. But using a button is better in such cases...
et-al 9y ago
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/void https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Back then, you'd use it with the `href` attribute to prevent the link from going anywhere (it would return `undefined`), then call a function with the `onclick` attribute. E.g. <a href="javascript:void(0)" onclick="clickHandler()">Click me</a>
ChrisSD 9y ago
Basically it defers to a javascript function instead of using the web's normal way of linking. An example of such a link would be: <a href="javascript:void(0)" onclick="dostuff()">Click me</a> href="javascript:void(0)" basically tells the browser to do nothing when a link is clicked. It's like returning false from an event listener. onclick="dostuff()" will then listen for clicks and call the `dostuff` function to update the page or load a new one. Nowadays it's considered bad practice and to be honest it wasn't exactly good practice in those days but it was very commonly used.

pqh 9y ago

Use case for labelled breaks: collision detection in video game, where anything colliding with anything else ends the game, resets a counter, spawns Godzilla, who knows. With labels, you can break out of the top loop very efficiently.

deleted 9y ago
[deleted]
throwanem 9y ago
You can't efficiently get back into it, though, which can be a problem for a game's event loop. If you wrap it in a function, you can return from that function anywhere inside the loop, and let its caller handle whatever state change incurred the exit and then restart the loop, if it wants, by calling the function again. On the other hand, if the event loop's job also includes rendering the game's UI, then leaving it by any means will freeze the display until it's restarted. That's probably bad too, although I suppose in theory it could be turned into a game mechanic. Absent that, this technique might make more sense in a case where you're running the exitable loop in question on a secondary thread (i.e. a worker), and doing things with it which can be safely interrupted - maybe changing levels or something, where the player isn't expecting to do anything during a UI transition, and you need to await the arrival of some resources over the network and then set up the game state before restarting the event loop to resume normal play? I don't know, that's a bit contrived and probably flawed in a critical way, but I think it makes the same basic sense as offloading heavy and necessarily synchronous work to a worker thread does in general.

eridius 9y ago

It used to be fashionable to use `void 0` for undefined values, both because it's shorter and because it used to be the case that you could actually redefine `undefined` to have some arbitrary value.