bopjesvla
Elixir and misspelled keyword list options
A lot of functions in the standard library trod along happily if a misspelled keyword list option is passed:
iex(3)> String.split("a1a11a", "1", triim: true)
["a", "a", "", "a"]
Compare to Python, which has keyword arguments baked into the language:
>>> from sklearn.linear_model import LogisticRegression
>>> LogisticRegression(qwerty=5)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __init__() got an unexpected keyword argument 'qwerty'
The Elixir behavior has bitten me many times. Putting the onus on the developer to check whether options are all valid isn’t working in my opinion, given that these kinds of checks are incredibly rare. One solution is to add a helper function to the standard library:
defaults = [opt: false, another_opt: true, rare_opt: 5]
correct_opts = [opt: true, another_opt: false]
Options.get!(correct_opts, defaults)
# [opt: true, another_opt: false, rare_opt: 5]
misspelled_opts = [blopt: true, another_opt: false]
Options.get!(misspelled_opts, defaults)
# throws, since blopt is not in defaults
This solution is too verbose, I think, since it requires developers to name all options at least once more than they usually would. The reason why this is almost a non-issue in Python is that it would take more effort to allow misspelled keyword arguments. With that in mind, I think the use of macros might be warranted.
def my_fun(positional_arg, opts \\ []) do
options!(opts, my_opt = false, another_opt = true, rare_opt = 5)
IO.inspect(rare_opt) # the value passed for opts[:rare_opt]
end
my_fun("pos_arg", my_opt: true)
my_fun("pos_arg", fake_opt: true) # throws
The intended behavior is that of keyword arguments in Python, meaning that the options are accessible as another_opt rather than opts[:another_opt] after the options! macro call.
I don’t necessary like the assignment syntax hijacking, but I do think a solution of this kind is called for.
Trending in Discussions
Other Trending Topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #elixirconf-us
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #performance
- #security










First 6 of 6 Posts!
lpil
This doesn’t need to be a macro, you could implement a function that takes the desired keywords from the list and throws on any unexpected keywords
Phillipp
I would find that very annoying during development. Often when playing around, I put a spelling mistake in an optional keyword to temporarily disable it (for fiddling around etc.).
Qqwy
I built the library Specify for situations where we want to make explicit what options are supported somewhere (and what defaults are used for them).
As for the behaviour of functions built-in to Elixir: I agree that in many cases it would be preferable for the function to crash rather than to silently ignore an unrecognized keyword. In some cases this currently happens but seemingly not everywhere.
That said, if you were to currently write code like this:
then if we were to call it with
OptionsExample.foo(10, 20, unexistent: 42)then we will get a FunctionClauseError that highlights what values were passed as well as which function clauses were attempted:Writing code like this is already a very lightweight way to create the behaviour you are suggesting.
bopjesvla
That’s only lightweight if a function has 1 option, though, especially since keyword lists are ordered. If a function has 4 options you’d probably need tens of function clauses.
The most radical solution, of course, would be to extend
defto deal with parsing options:But I think the
option!macro I suggested would be sufficient.Qqwy
I stand corrected.
slashdotdash
The NimbleOptions library by Dashbit provides a way to validate Keyword lists by validating the options against a definition. The examples below are from the README.