[erlang-questions] The gen server simplified (how it works)

[Torben Hoffmann]

On Thu, Apr 21, 2011 at 12:08, Jeroen Koops <koops.j@REDACTED> wrote:

>
>
> On Wed, Apr 20, 2011 at 11:44 PM, Torben Hoffmann <torben.lehoff@REDACTED
> > wrote:
>
>>
>>
>> On Wed, Apr 20, 2011 at 15:09, Jeroen Koops <koops.j@REDACTED> wrote:
>>
>>>
>>>> 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.
>>>>
>>>>
>>> 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.
>>>
>>
>> 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.
>> I have done that many times and it works rather well.
>>
>> 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?
>
>
Well, yes and no.
In terms of code evolution I feel that you risk being stuck with gen_server
when gen_fsm would be the right choice.

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.)

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.

Cheers,
Torben
-- 
http://www.linkedin.com/in/torbenhoffmann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110425/4a2b124e/attachment.htm>