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

Mazen Harake mazen.harake@REDACTED
Thu Apr 21 13:19:33 CEST 2011

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

> 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?

 When you say "an event should be handled in one way in one particular
state, and in another way in _all_ other states" you are essentially talking
about a state flag. That flag is a substate of a larger state and it is
wrong to compare a state you are in (e.g. as in a gen_fsm state) and a state
which you carry to each state (namely the substate or the "State" variable
in the gen_fsm if you will).

This mix of states (where you use the "State" variable in a gen_server as a
variant of gen_fsm's "nextstate") is not recommended but I have seen it a
lot. I think this boils down to design firstly and laziness secondly;
Developers don't want (as you say) to implement 9 other states that handle a
specific message just because 1 state should do it in a special way.

What we should have is a gen_fsm which takes "Mod:handle_state(State::atom(
), ...)" rather than "Mod:State(...)" so that we can match on the state in
the function header.... but then again... we would be reinventing the wheel
because that is what most of us (including me) are already doing sometimes
in gen_servers (by moving this state into a substate).

Moral of the story, they are not the same and if you end up in a situation
that requires a lot of these "state flags" then perhaps a gen_server is not
the solution, but also if you have too many "general" states with very few
exceptions then perhaps a state flag is more appropriate.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110421/f436895d/attachment.htm>

More information about the erlang-questions mailing list