'Dynamic Calls'

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

'Dynamic Calls'

duncan
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 'Dynamic Calls'

Jesper Louis Andersen-2
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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 'Dynamic Calls'

Brujo Benavides-2
Hi Duncan,

This is the reasoning behind the rule. As usual, Jesper explained it in a much much better way :)
Now, my question would be: If you have ~33 modules with the same function, why not defining a behavior for them?
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 ;)

Cheers!

On Apr 9, 2017, at 18:05, Jesper Louis Andersen <[hidden email]> wrote:

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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 'Dynamic Calls'

duncan
Jesper, Brujo,
Thank you. 
Wrt behavior/callbacks - The main reason I'm not using callbacks is due to my ignorance. I sort of know how to use them (obviously not fully understanding them) when others design the behavior and I use it, but I haven't made any myself. The 33 modules are all gen_servers and I think the modules I'm calling are the public api (eg in this case calling the stop function which sends a stop message to a selected subset of them). I don't understand what the behavior would be and the callbacks in this case for the 'stop a selected subset of servers' function.
Duncan

iPhone, iTypo, iApologize

Duncan Sparrell
sFractal Consulting, LLC
The closer you look, the more you see
_____________________________
From: Brujo Benavides <[hidden email]>
Sent: Monday, April 10, 2017 8:45 AM
Subject: Re: [erlang-questions] 'Dynamic Calls'
To: Jesper Louis Andersen <[hidden email]>
Cc: <[hidden email]>, <[hidden email]>


Hi Duncan,

This is the reasoning behind the rule. As usual, Jesper explained it in a much much better way :)
Now, my question would be: If you have ~33 modules with the same function, why not defining a behavior for them?
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 ;)

Cheers!

On Apr 9, 2017, at 18:05, Jesper Louis Andersen <[hidden email]> wrote:

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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...