<div dir="ltr"><div>OK, I'll try to give you my opinion on this topic. If I understand your question correctly. </div><div>It may look rude but please believe me it is not my intention to be rude.</div><div><br></div><div>Your examples for me are the evidence of the "classic OOP" poisoning.</div><div>Remark:</div><div>I call it "classic" based on how the vast majority of the developers perceive the idea of objects and</div><div>interaction between them. </div><div>Though I am on the side of Alan Kay's definition of the OOP - objects communicating with messages.</div><div><br></div><div>Anyway, how you "slice" the world and how you make your abstractions - it is influenced by the "classic OOP".</div><div>Erlang is the functional language (more or less) so abstractions are made the other way:</div><div>1. Basic units are Module and Function;<br></div><div>2. Dynamic function calls - Module:Function(Args). So you can dynamically (in runtime) change the module;</div><div>3. Behaviour is just a hint for a compiler to check a Module for a presence of the required functions.</div><div><br></div><div>Based on these 3 points - when you write -behaviour(....) in a module you are just saying that</div><div>this module must have a bunch of functions implemented to be successfully compiled. It is not for</div><div>supporting your own abstractions. It is an instrument to remind you to implement functions.</div><div><br></div><div>What you call "general" functionality in Erlang is simply a library implemented as module(s).</div><div><br></div><div>Of course it is very tempting to call behaviour an interface, because it looks like an interface.</div><div>But it is not because the interface in Erlang are the functions, not a separate entity.</div><div><br></div><div>Example of using behaviour from my own experience.</div><div>As in almost any application I must have something where I store the data.</div><div>And requirements are very vague. So I don't know if it would be Mnesia, PostgreSQL, file, space station or a toaster.</div><div>So I've made the behaviour which defines functions for my business logic associated with storage.</div><div>To make it simple it is like the CRUD operations on my entities. </div><div>This behaviour is implemented as an independent rebar3 library, so other parties (sometimes remote) can include it as a dependency.</div><div>But their implementations are included in the final application and what implementation will be used</div><div>is defined in the configuration file. </div><div>(Pseudo) code is like this:</div><div><br></div><div>callbacks_db.erl:</div><div>    -module(callbacks_db).</div><div>    -callback create(Entity::my_entity_t()) -> ok | {error, Result :: term()}.</div><div><br></div><div>postgresql.erl:</div><div>    -module(postgresql).</div><div>    -behaviour(callbacks_db).</div><div>    create(Entity) -> ....</div><div><br></div><div>toaster_able_to_storage_data.erl:</div><div>    -module(toaster_able_to_storage_data).</div><div><div>    -behaviour(callbacks_db).</div><div>    create(Entity) -> ....</div><div><br></div></div><div>main_app.config:</div><div>     {main_app, [</div><div>         {db, #{mod => postgresql}} % If you are using a toaster use "toaster_able_to_storage_data"</div><div>     ]}</div><div><br></div><div>main_app.erl:</div><div>    some_function(DBMod) -></div><div>        Entity = create_entity(...),</div><div>        DBmod:create(Entity).</div><div><br></div><div>That is all about behaviour.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 25 авг. 2021 г. в 00:46, Brett Hemes <<a href="mailto:brhemes@mmm.com">brhemes@mmm.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_2539447114573187841WordSection1">
<p class="MsoNormal">> Erlang's behaviour is NOT an interface!<u></u><u></u></p>
<p class="MsoNormal">> If you are looking for some analogy from other languages the closest one is abstract classes in C#.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This isn’t very helpful...  it is the exact same response I find in the forums with no reasoning behind it.  I don’t need analogies either; I understand what behaviours are “supposed” to be from the documentation and comments (perhaps this
 wasn’t made clear by my post).  Where I fall short is “why” are behaviours limited to such and why aren’t more people asking the same questions I am stuck on (regarding polymorphism)?  My logic was: yes, this has been asked and discussed some in the past with
 no real resolution that I could find... therefore, users must be content/accepting of the tools provided.  I am not so naive to think I am the first to need/want such, so there must be a disconnect.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I posted my example to motivate my questioning hoping for some insight and/or comfort.  As of now, I have proceeded with storing “meta refs” to my child servers that are module/reference tuples (along with some dangerous and future-maintenance-issue-causing
 assumptions regarding their “interface”)... and it’s works... it just smells, and I am always eager to learn and find the right/better/best way.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Aside: a colleague came across this repo (<a href="https://github.com/eldarko/epolymorph" target="_blank">https://github.com/eldarko/epolymorph</a>) while digging and the readme seems to capture my use case almost exactly...<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Brett<u></u><u></u></p>
</div>
</div>

</blockquote></div></div>