I recently worked on some code where I wanted to store {key, value}-pairs
and newer values entered for the same key should shadow older values.
So, I tried using Keyword lists.
However, the keys in my list were not atoms but Strings -- they contain
properties that users might enter, and therefore it is unsafe to work with
atoms directly (as they are never garbage collected, at some point they can
and will make your system run out of memory).
But then this turned out not to work! Keyword requires keys to always be an
atom <http://elixir-lang.org/docs/stable/elixir/Keyword.html#content>.
This choice has been made deliberately in the past (the documentation
clearly states it, using the access protocol for keywords will throw a
descriptive error message, etc.),
but it is unclear why.
Above use case seems relatively general to me.
For instance, OptionsParser.parse/1 always returns a Keyword list with
atoms right now, and suffers from the atom-garbage-problem because of it.
(OptionsParser.parse/2 allows you to specify what switches should be
allowed, but this is not appropriate for all use cases)
Why is the current behaviour as it is right now?
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/69fe6eeb-19a1-4edf-8908-ddfe70734b60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
