Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Its an interesting question because it involves the fundamentals of functional design.</p> <p>My opinion: Try as much as possible to make the function return the messages, then send them. This separates the two different tasks nicely, and separates the purely functional task from the one that causes side effects.</p> <p>If this isn't possible, pass receivers as argument even if its a bit messy. If the broadcasting function uses that data, it should be given to it explicitly, for clarity and predictability.</p> <p>Using ETS as Peer Stritzinger suggests is really not any better than the PD, both hides the fact that the broadcasting function uses the receiver list and makes it dependent on global data.</p> <p>I'm not sure about the Erlang way of encapsulating some state in a process, as I GIVE TERRIBLE ADVICE suggests. Is it really any better that ETS or PD?</p> <blockquote> <p>clutters up my dispatcher with a bunch of {Msg, NewState}</p> </blockquote> <p>This is my experience also, that you often end up like this. It's not particularly pretty, but functional design seems to encourage this. Could some language feature be introduced to make it more beautiful and natural?</p> <h2>EDIT:</h2> <p>6 years ago I wrote:</p> <blockquote> <p>Could some language feature be introduced to make it more beautiful and natural?</p> </blockquote> <p>After learning much more about functional programming I have realised that examples of this are monads and <a href="https://en.wikibooks.org/wiki/Haskell/do_notation" rel="nofollow">do-notation</a> that are found in Haskell.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload