12 ms·

Some hard earned wisdom: Callbacks (whether asynchronous or not) have the advantage of being extremely modular. The callee can just do what needs to be done - s

Some hard earned wisdom: Callbacks (whether asynchronous or not) have the advantage of being extremely modular. The callee can just do what needs to be done - since the contract is simply a call to a function with a very simple signature, this will hardly ever be a (dependency / maintenance) burden. On the other hand, https://twitter.com/sempf/status/917962985582231552 https://twitter.com/sempf/status/917962985582231552 I suppose experienced developers do as little as possible in callbacks (basically store the event away and make a note that there was something, at a central place). Then try to do everything else in easy to understand main control flow, some time later.

ambrop7 9y ago
> I suppose experienced developers do as little as possible in callbacks (talking about C/C++ mostly) I have personally come to embrace the opposite approach: let callbacks do absolutely anything someone could do outside of a callback. This way, code gets simpler and clearer. For example, if a Socket object contained in HttpConnection calls back to HttpConnection telling it the connection is dead, the HttpConnection class should be able to just do something like "server->connections.remove(this); return;". Yes that remove is HttpConnection self-destructing; after that statement HttpConnection and the Socket no longer exist. Ensuring safety of this is really simple: whenever you call a callback, the next statement must be "return" and more specifically you must return back to who called you without touching anything which might be dead now. Or perhaps more idiomatically you can "return callback();" when both the callback and the calling function return void. In the case that you would want to do something after the callback is done, instead ask the event loop to call you "soon", and make sure your destructor will cancel that. For example this can be just a timer with zero timeout, or a special event queue designed for this purpose (in which case LIFO scheduling will get you natural "recursive" evaluation order).
- passthefist 9y ago
  > Or perhaps more idiomatically you can "return callback();" when both the callback and the calling function return void At least in JS I think that is idiomatic, it's an option for linting: https://eslint.org/docs/rules/callback-return https://eslint.org/docs/rules/callback-return.
dahart 9y ago
> I suppose experienced developers do as little as possible in callbacks (basically store the event away and make a note that there was something, at a central place). Then try to do everything else in easy to understand main control flow, some time later. This is why there's a trend toward frameworks that are a giant pub-sub, like React/Redux. The pattern is essentially to forward UI events (mouse clicks, etc) to the pub-sub, and that way you can keep all code together in the main control flow, in a somewhat "functional" style.

ambrop7 9y ago

> I suppose experienced developers do as little as possible in callbacks (talking about C/C++ mostly) I have personally come to embrace the opposite approach: let callbacks do absolutely anything someone could do outside of a callback. This way, code gets simpler and clearer. For example, if a Socket object contained in HttpConnection calls back to HttpConnection telling it the connection is dead, the HttpConnection class should be able to just do something like "server->connections.remove(this); return;". Yes that remove is HttpConnection self-destructing; after that statement HttpConnection and the Socket no longer exist. Ensuring safety of this is really simple: whenever you call a callback, the next statement must be "return" and more specifically you must return back to who called you without touching anything which might be dead now. Or perhaps more idiomatically you can "return callback();" when both the callback and the calling function return void. In the case that you would want to do something after the callback is done, instead ask the event loop to call you "soon", and make sure your destructor will cancel that. For example this can be just a timer with zero timeout, or a special event queue designed for this purpose (in which case LIFO scheduling will get you natural "recursive" evaluation order).

passthefist 9y ago
> Or perhaps more idiomatically you can "return callback();" when both the callback and the calling function return void At least in JS I think that is idiomatic, it's an option for linting: https://eslint.org/docs/rules/callback-return https://eslint.org/docs/rules/callback-return.

dahart 9y ago

> I suppose experienced developers do as little as possible in callbacks (basically store the event away and make a note that there was something, at a central place). Then try to do everything else in easy to understand main control flow, some time later. This is why there's a trend toward frameworks that are a giant pub-sub, like React/Redux. The pattern is essentially to forward UI events (mouse clicks, etc) to the pub-sub, and that way you can keep all code together in the main control flow, in a somewhat "functional" style.