Is this also applicable to values we are setting in the config.exs like:
config :my_app, x: Enum.to_list(1..1_000_000)
And then calling for the “const”:
defmodule Foo do
def foo, do: Application.get_env(:my_app, :x)
def bar, do: Application.get_env(:my_app, :x)
end
Because this is usually the way I’m defining and using my constants..
Regarding the subject of constants, I think we are already all good in Elixir and here is my 2cts (biased because of my background in C)..
If I do, a = 2 * 3.14 * r, I guess everyone will get that this is pi.. But not everyone will grab what 0x89504e47 is.. So doing PNG_SIGNATURE=0x89504e47 is pretty sane… And that still would apply for pi PI=3.14159 so this allows to reuse it without introducing typos.. (although for this example we have a better option of course by using :math.pi())
But if this was a regular variable, the risk to have it modified elsewhere in the codebase would be not null..
So often we use constants to make a given literal value being meaningful and to actually have it read-only.
So using functions (actually like pi() in :math) or even putting it as a config is exactly solving these two use cases.
IMHO, putting all the constants in one place like we do in Elixir apps within the config is the way to do it or within a module (I like to have MyApp full of my constants and magic numbers or submodule if I want to namespace them). This is my argument about being all good in Elixir.
Of course we can still use for one-file uses cases the module attributes (like we for fields in Schemas or like in test files with attributes, etc.).
But I can see the following addition (to the formatter at least), maybe we can add a module attribute to tell that the following function is intended to be a constant and then allowing for that function to be used without parentheses (and maybe bring some optimization as well regarding memory mapping).
defmodule Math do
@constant #or whatever keyword
def pi, do: 3.141592653589793
end
MyMath.pi # vs Math.pi() enforced by the formatter
# Some people don't like not having them all uppercase..
# But even if we allow to use uppercase only in this situation,
# Math.PI will definitely be confusing as a module in Elixirland
# Math.pi might also recall as a map field, which is semantically equivalent here, so win-win
Anyway, sorry for this long message and hope it makes sense..
That makes sense, I’ll link it in the blog post and of course it’s already documented… maybe I should go and read the entire docs again at some point for all the great stuff that has been added!