<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Duncan,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/basho/erlang_guidelines#avoid-dynamic-calls" class="">This</a> is the reasoning behind the rule. As usual, Jesper explained it in a much much better way :)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Now, my question would be: If you have ~33 modules with the same function, why not defining a behavior for them?</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Simply adding a proper -callback (and maybe -optional_callbacks(…)) attribute(s) to your module where you have the dynamic call and -behaviour(…) to the others will not only remove Elvis warning but also let the compiler check if you’re doing things right ;)</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Cheers!</div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 9, 2017, at 18:05, Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com" class="">jesper.louis.andersen@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Usually, it is a trade-off between readability, dialyzer/xref precision, and generality.<div class=""><br class=""></div><div class="">The price of using many dynamic modules is that you can't use something like grep(1) anymore to find out who are callers. Likewise, tools usch as xref fails to see the call graph. This argues the notion should be used with care, although there are many good reasons for dynamically invoking a module as well.</div><div class=""><br class=""></div><div class="">What to do depends on the problem. Sometimes code can just be rewritten to something simpler. Other times, you can create a callback system and use that. Or you may be able to let a target process vary. And of course there are situations where the best approach is to just use dynamic modules in the code base.</div><div class=""><br class=""></div><div class="">A somewhat sound advice is to make sure there are few dynamically injected modules and that they are not subject to change as the system runs. Otherwise, the code may be hard to follow for a newcomer.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Apr 9, 2017 at 9:32 PM <<a href="mailto:duncan@sfractal.com" class="">duncan@sfractal.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><span style="font-family: Verdana; font-size: 10pt;" class="gmail_msg"><div class="gmail_msg">I use the "standard" elvis rules for checking my code and I'm getting an error I'd like to understand the reasoning behind the rule. The error I'm receiving is:</div><u class="gmail_msg"></u><span class="gmail_msg m_2657325814527349327pre"><span class="m_2657325814527349327white gmail_msg"><span class="gmail_msg m_2657325814527349327brwhite">invalid_dynamic_call</span>
<span class="gmail_msg m_2657325814527349327brwhite"> - Remove the dynamic function call on line 47. Only modules that define callbacks should make dynamic calls</span></span></span><p class="gmail_msg">The line in question is </p></span></div><div style="padding-left:30px" class="gmail_msg">Svr:stop(),<br class="gmail_msg"></div><div class="gmail_msg">so the module is variable which is bound to an atom from a list in a state map (ie the servers to which a message should be sent, in this particular case it's a stop message).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">My first question is what is the reasoning behind the elvis rule (ie what's wrong with dynamic calls)?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">My followup question is what should I do instead? Note that making a function head for every potential choice (33 at moment) is doable for this case but seems tedious and what if the number was much larger (which it will be in other parts of the simulator being built)?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Duncan Sparrell</div><div class="gmail_msg">sFractal Consulting LLC</div><div class="gmail_msg">iPhone, iTypo, iApologize</div>
_______________________________________________<br class="gmail_msg">
erlang-questions mailing list<br class="gmail_msg">
<a href="mailto:erlang-questions@erlang.org" class="gmail_msg" target="_blank">erlang-questions@erlang.org</a><br class="gmail_msg">
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" class="gmail_msg" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br class="gmail_msg">
</blockquote></div>
_______________________________________________<br class="">erlang-questions mailing list<br class=""><a href="mailto:erlang-questions@erlang.org" class="">erlang-questions@erlang.org</a><br class="">http://erlang.org/mailman/listinfo/erlang-questions<br class=""></div></blockquote></div><br class=""></body></html>