Dynamic Functions

[elbrujohalcon]

Rule

Don't use dynamic function calling outside of behaviour modules with callbacks

Options

• Ignore modules

[mpmiszczyk]

On one hand great rule. We found with it few places we could improve our code with it.

On other we have some issues with this one. Especially with making it go away. This one assumes that all callback have to be defined in module that uses them. And this is not always our case.

Personally I prefer to create separate module that just have callback. Like this one. This is especially useful when more than one module uses same kind of behaviour.

Second use case is when one module uses two types of behaviors. For example we could have generic algorithm that handles interactions of cats and dogs. So you could have both calls like CatModule:boots() and DogModule:with_bone(). So you should have two different behaviors defined, but one module can define only one.

Our solution (not to pass Elvis rule, but rather to keep code clean/readable) would be specs. To be exact we define and export type from callback module, like type cat_module() :: module()., which is enough to keep functions readability (without any actual type-checking of course).

So maybe some modification of this rule would be a good idea ?

[mpmiszczyk]

There is a third option:

We define callback module, with functions calling callbacks:
https://github.com/ParaPhraseAGH/parallant/blob/simplify/src/world_impl.erl

And all the clients call callback-module which calls callbacks implementations.
https://github.com/ParaPhraseAGH/parallant/blob/simplify/src/parallant.erl#L135

Not sure if you had in mind such pattern when you designed this rule, but this is good for both to Elvis rule, and our use case problems. And i think I like it, even little more than dynamic calls.

Huge kudos to @pianiel for coming up with such solution.

[elbrujohalcon]

@mpmiszczyk I understand your two scenarios and, to cope with things like that is why we added a list of module exceptions to the rule. Because we couldn't find a different way to be sure that a call to Module:some_function() will be valid because Module will be implementing a behaviour that defines some_function/0.