<br><br><div class="gmail_quote">On Thu, Apr 21, 2011 at 12:08, Jeroen Koops <span dir="ltr"><<a href="mailto:koops.j@gmail.com">koops.j@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Wed, Apr 20, 2011 at 11:44 PM, Torben Hoffmann <span dir="ltr"><<a href="mailto:torben.lehoff@gmail.com" target="_blank">torben.lehoff@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Wed, Apr 20, 2011 at 15:09, Jeroen Koops <span dir="ltr"><<a href="mailto:koops.j@gmail.com" target="_blank">koops.j@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div>The most common form of gen _server abuse I have seen (and I plead guilty of it myself) is attempting to turn it into something akin to a state machine. My rule of thumb is if your state record contains a field called state or something like it and you take different actions based on it, then it's time to re-factor into a gen_fsm. It's easy to get into this situation since things usually start simple and build up once more functionality is piled on. </div>



<div><br></div></div></blockquote><div> </div></div><div>I don't know about this -- I have written numerous gen_servers whose state-record include a state-field (although I usually call it 'current'), and events (calls, casts, infos) are handled differently depending on its value. The reason for not using a gen_fsm is that very often, an event should be handled in one way in one particular state, and in another way in _all_ other states. This is easy to do using pattern-matching when using a gen_server, but when using a gen_fsm you have no choice but to write out every state/event combination, which can become pretty cumbersome.</div>


</div></blockquote></div><div><br>Then one can use an gen_fsm:send_all_state_event/2 and pattern match on both state and state date that in the modules handle_event/3 function.<br>I have done that many times and it works rather well.<br>

<br></div></div></blockquote></div><div>Of course, but when you do that for the majority of the events it amounts to the same as using a gen_server with a 'state'-field, doesn't it? </div></div><br>
</blockquote></div><br>Well, yes and no. <br>In terms of code evolution I feel that you risk being stuck with gen_server when gen_fsm would be the right choice.<br><br>Even if most of your events are send_all_state_event's you do gain more information with gen_fsm due to the structure of the callback functions. I have exploited that to create a little program that can produce a CSP description of a gen_fsm, which is good for communication with people who have a hard time reading Erlang code. I think it would have been harder to write that program using the gen_server + state approach, but that is guess work! (The program was very specific to the code style we used, so there is nothing to share.)<br>
<br>My experience is probably also tainted by the fact that I have mostly implemented telecom protocols and they fit best with gen_fsm and have only a few all state events.<br><br>Cheers,<br>Torben<br>-- <br><a href="http://www.linkedin.com/in/torbenhoffmann">http://www.linkedin.com/in/torbenhoffmann</a><br>