OCaml provides a facility to parameterize modules (modules which accept other modules as arguments) through functors (this is different from functor algebraic data type).
Example:
module Increment (M : X_int) : X_int = struct
let x = M.x + 1
end;;
I am curious if there is a popular idiom similar to this in elixir, where a module can depend on multiple other modules, which can be swapped in later (potentially with different module arguments) to get composite modules.
What do you mean by module arguments? And how a module would depend on other modules, through a use macro? You can probably define a protocol to which your module implementations would adhere, but that would only provide some kind of polymorphism so that conforming modules could be “swapped in later” …
What do you mean by module arguments?
And how a module would depend on other modules, through a use macro?
Module X depends on Module Y and uses functions exposed in module Y. However when I define module X I don’t specify what that module Y is, rather it is an argument.
Later I can pass a compatible implementation of Y, say Y1 to X as a parameter and get a module X1 which uses Y1.
This article by Dr. Axel Rauschmayer explains it in much more detail.
You can probably define a protocol 1 to which your module implementations would adhere, but that would only provide some kind of polymorphism so that conforming modules could be “swapped in later” …
Yes, I understand that protocols are the primary solution for polymorphism in elixir.
Parameterised modules are somewhat more generic given that it does not necessarily have to resolve the implementation based on the signature of a struct. The consumer of the generic module is free to pass in any compatible module and the implementation will use that.
I meant what do you mean by that in terms of elixir. Do you define module dependencies using some macro? I’m not aware of any support for it in the language itself.
The more idiomatic way is to pass in the “compatible” module as an argument to Xs functions.
Oh ok. I didn’t realize elixir modules were first class values. Thanks.
Modulenames are just atoms. This is what makes this possible.
There is an idiom used when a library defines a module that must be instantiated by the application that uses it, along with some configuration.
Ecto.Repo is an example:
defmodule MyApp.Repo
use Ecto.Repo, otp_app: MyApp
end
The otp_app keyword argument allows Ecto.Repo to lookup the remaining configuration with Application.get_env(app, __MODULE__)
In simpler cases the config can be passed directly into use.
You can pass module atom names around all you want and call them directly, so yes. (The OCaml Witness Pattern via First-Class modules)
If however you are refining a module based on another module (a limited form of OCaml Functors), Elixir/Erlang does have first-class support for that currently in the form of tuple-calls, however that feature is being broken soon much to my irritance… >.>
What are tuple calls?
For all purposes, it is an undocumented feature and it may be removed from Erlang anytime.
Tuple calls are already disabled by default on Erlang/OTP 21 and they explicitly require a @compile option on every module that needs them.
Afaik it’s not only “may be removed”, but it’s already gone in OTP 21.
No it’s still there, just you have to set a compile option on the file to enable it’s usage. I’m quite angry at that though, it’s more useless work for the user…
© Copyright Elixir Forum | Terms | Privacy & Cookies
