[erlang-questions] Best practices in gen_fsm usage

[Robert Virding]

Of course, you don't NEED gen_fsm as you can always carry an extra field in the loop data which indicates which state you are in. You can also flip that and say you don't really NEED gen_server as this is just a gen_fsm with one state.

The point is that using one or the other more clearly shows your intent and is therefore a Good Thing (tm).

I think this is also the with using send_all_state_event, it is an event which is allowed in all states. Of course, you can add a clause to each state function to handle that event, but using the send_all_state_event better shows the intent.

I don't really see why you would not wrap the actual gen_fsm:send_event/2 call in a user API, as you would do with gen_server:call/2. If you can hide the detail of the actual request being sent then you most often should do that.

Robert

----- Original Message -----
> On Wed, Dec 7, 2011 at 6:50 PM, Adam Lindberg
> <adam.lindberg@REDACTED> wrote:
> 
> >
> > What exactly is the use case for being able to contact a process
> > that implements either gen_server or gen_fsm via a standard API?
> > I've never come across a use case where processes of different
> > "types" needed to be mixed. If you really, really have to have
> > that, you could implement a common interface via the handle_info/2
> > callbacks.
> 
> You haven't met. I have.
> 
> >
> > - Either your process runs code that is based on gen_fsm, then you
> > use a wrapper API that converts calls to corresponding gen_fsm
> > calls (just as Thomas suggested).
> >
> 
> What for?
> 
> I have never ever seen any _production_ code, which is better with
> gen_fsm. Thanks to Fred for study examples, but they are study
> examples.
> 
> Ulf told something about SDL, but I really don't know what is SDL.
> 
> I beleive that there may be situation, when gen_fsm is convenient.
> But
> I ask only to show example of such code.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>