<div dir="ltr">A behaviour behaves in some specific way, and importantly the behaviour is common enough (can be used repeatedly) to define it separately.<div><br></div><div>A behaviour exposes two sets of APIs. One set facilitates the communication with external processes. The second one facilitates to define the behaviour of it. The second set is also called call back functions.</div><div><br></div><div>The second set is like a contract that a call back module for a behaviour should adhere to.</div><div><br></div><div>There may or may not a mapping between the two sets of APIs.</div><div><br></div><div>It is the responsibility of the behaviour defining module to call the functions in the callback module when the triggering points are reached.</div><div><br></div><div>When you are using behaviours, you can use multiple of them meaningfully in a single module. This is called cascading behaviours.</div><div><br></div><div>Theepan</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 15, 2015 at 1:34 PM, Frans Schneider <span dir="ltr"><<a href="mailto:schneider@xs4all.nl" target="_blank">schneider@xs4all.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    
    Hi list,<br>
    <br>
    I find myself repeating code in several gen_server and gen_fsm
    behavior based modules. These modules should all share about eight
    functions, all doing exactly the same thing. On top of these
    modules, more elaborate modules with common functions have to be
    defined, adding four or so functions. To me, this is looking like
    defining my own custom behaviors.<br>
    I had a look at the implementation of the Erlang supervisor for
    extending the gen_server behavior which gives enough information to
    get something working. However, I have no glue how to extend the
    gen_fsm behavior and keep the interface to defining states in the
    new behavior.<br>
    So, what I am looking for is some reference material on writing
    custom behaviors on top of what Erlang central and the OTP
    documentation offer. <br>
    <br>
    TIA,<br>
    <br>
    Frans<br>
    
    
    
  </div>

<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>