<br><div class="gmail_quote">On 7 December 2011 14:49, Thomas Lindgren <span dir="ltr"><<a href="mailto:thomasl_erlang@yahoo.com">thomasl_erlang@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
>________________________________<br>
<br>
> From: Maxim Treskin <<a href="mailto:zerthurd@gmail.com">zerthurd@gmail.com</a>><br>
...<br>
<div class="im">><br>
>1. gen_fsm incompatible with gen_server. We cannot use synchronous call from gen_server for gen_fsm because it different.<br>
>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?<br>

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

><br>
><br>
>Is there any best practices in gen_fsm usage? May be I and other people uses gen_fsm improperly?<br>
><br>
<br>
</div>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.<br>

<br></blockquote><div>Yes, this solution is acceptable, but it is yet another redundant layer of abstraction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Best,<br>
Thomas<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Maxim Treskin<br>