[erlang-questions] Best practices in gen_fsm usage
Wed Dec 7 14:41:45 CET 2011
On Wed, Dec 7, 2011 at 7:56 AM, Maxim Treskin <zerthurd@REDACTED> wrote:
> On 7 December 2011 14:49, Thomas Lindgren <thomasl_erlang@REDACTED> wrote:
>> > From: Maxim Treskin <zerthurd@REDACTED>
>> >1. gen_fsm incompatible with gen_server. We cannot use synchronous call
>> > from gen_server for gen_fsm because it different.
>> >2. Two different actions: send_event и send_all_state_event with
>> > different handlers. Why? If we want to send message to FSM, we just send
>> > message to process without knowledge of its internal state-related issues,
>> > right?
>> >3. For complex protocols and when one message emits almost equal actions
>> > in various process states, code of gen_fsm-process becomes
>> > pumpkinized. Every time I start writing a new gen_fsm module, I think that
>> > this time the code will not become pumpkinized, but this wrong. Large number
>> > of pattern matching with records in events and internal state of process in
>> > various state handlers makes code duplicated and unreadable.
>> >Is there any best practices in gen_fsm usage? May be I and other people
>> > uses gen_fsm improperly?
>> Regarding points 1 and 2: My favorite approach to using gen_fsm,
>> gen_server etc is to define all the calls to the server/fsm/... as an API,
>> often in the server module itself. The client then just uses these API
>> functions, while it's the job of the provider module to wrangle the raw
>> gen_* calls.
> Yes, this solution is acceptable, but it is yet another redundant layer of
Just because we are functional programmers doesn't mean we should
throw away encapsulation. I *love* this method, because it completely
hides the fact I'm using gen_fsm - which after all is only an
implementation detail, and shouldn't matter more than that.
In fact in Hypernumbers, I think almost every single gen_server or
gen_fsm has an official API of functions that call into gen_*:call(),
but without ever invoking that directly. (Yes they do cope with the
fact that there might be multiple processes all using the same
> Maxim Treskin
> erlang-questions mailing list
+44 (0)7891 993 664
More information about the erlang-questions