[erlang-questions] 'Dynamic Calls'

[Jesper Louis Andersen]

Usually, it is a trade-off between readability, dialyzer/xref precision,
and generality.

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.

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.

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.

On Sun, Apr 9, 2017 at 9:32 PM <duncan@REDACTED> wrote:

> 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:
> invalid_dynamic_call - Remove the dynamic function call on line 47. Only
> modules that define callbacks should make dynamic calls
>
> The line in question is
> Svr:stop(),
> 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).
>
> My first question is what is the reasoning behind the elvis rule (ie
> what's wrong with dynamic calls)?
>
> 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)?
>
> Duncan Sparrell
> sFractal Consulting LLC
> iPhone, iTypo, iApologize
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170409/95a09bc4/attachment.htm>