I feel like a common idiom in Elixir is to define environment-specific
variables using module attributes so that each environment's changes can be
compiled directly (instead of being called dynamically). The most obvious
place to define these module attributes is in the respective config
Ah it looks like this is the case for standalone apps, but it's not the
case for sub-apps generated inside an umbrella project. That is, if I
change the config in one of my sub-apps then recompilation will not happen
and running `mix test` will not reflect changes to the sub-app's configs.
Today I'm studying Elixir protocols and stumbled upon something I found
Enumerable came to mind pretty quickly for me as a good example for
protocols. The interesting thing that I noticed is the default
implementations of Enumerable for Elixir types is a little underwhelming.
On Wed, 12 Oct 2016 20:03:59 +0200
José Valim wrote:
> The record/2 macro is defined in the Record module so I would keep things
> contained in the Record module and not link it to in typespecs, specially
> because it is a regular Elixir macro
It is for optimization purposes. We could implement all? on top of the
reduce but that would imply dispatching to the protocol, then to the
implementation and then process the reduce operation. So we skip all of
that by dispatching to the local implementation.
Another way to put it: sometimes you
I'm reviewing some documentation and I found this,
Types can be defined for tuples with the `record/2` macro (only available in
typespecs). This macro will expand to a tuple as seen in the example below:
defmodule MyModule do
The record/2 macro is defined in the Record module so I would keep things
contained in the Record module and not link it to in typespecs, specially
because it is a regular Elixir macro and not a typespec construct.
Founder and Director of R