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

[Jeroen Koops]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110421/d6318525/attachment.htm>