spacebat
Kword - A library of keyword-list handling functions to complement Keyword
A recent Reddit post Keyword.get Considered Harmful nudged me to tidy up and publish a small utility library that I’ve been using to deal with keyword lists in an ergonomic way.
Elixir keyword lists as a common representation of optional arguments to functions feels a bit clunky. You may find yourself writing something like:
def update_user_details(opts \\ []) do opts = Keyword.validate!(opts, [:name, :email, role: :guest, gender: :unspecified]) name = Keyword.fetch!(opts, :name) email = Keyword.fetch!(opts, :email) ... endThe intent of Kword is to enable list matching (there’s an order of parameters in the second argument) and to write instead:
def update_user_details(opts \\ []) do [name, email | _rest] = Kword.extract!(opts, [:name, :email, role: :guest, gender: :unspecified]) ... endIf you want to ensure required parameters are in fact supplied, use extract or extract!.
If you don’t want to allow parameters that aren’t specified, use extract_exhaustive or extract_exhaustive!.
And if you just want to pluck values out of a keyword list in the order specified, use extract_permissive which will default parameters to nil that have no default specified.
Perhaps I’ve missed something and this library isn’t actually useful, or there may be some improvement that would make it more worthwhile.
Most Liked
sodapopcan
“Considered Harmful” titles always make me think of “Considered Harmful” Essays Considered Harmful ![]()
I’m in favour of validating keyword args and do it myself (personally I use NimbleOptions) but that article hardcore handwaves through the entire premise of how they got there: how on earth did their tests not catch a mis-spelled option?? It sounds like they were passing the option but not actually asserting on its effects. Am I wrong or is there an obvious valid hiccup you can have here?
sodapopcan
While it’s getting outside the realm of options, keywords also allow us to have order matter in the rarer situations where that’s useful:
from q in query,
join: u in User,
on: u.id == q.user_id,
join: o in Org,
on: o.id == u.org_id
dimitarvp
I support everything that helps people make less mistakes and dynamic languages like Elixir don’t provide as much protection there.
So firstly, good job. ![]()
Secondly, the linked article does not sell the resulting library to me. Keyword.get and Map.get are something that many Elixir devs, myself included, consider an anti-pattern simply because they don’t discern between “I don’t have the key” and “I have the key but the value is nil” – in some situations this difference is meaningless but I’d bravely claim that in at least 80%, if not 90%, of the Elixir code I had to author or maintain that difference was in fact important but people ignored it and introduced bugs. So just by using functions like take and fetch you can replace most of the conveniences of this library – though granted, it would take more boilerplate so the library still looks compelling.
Thirdly, not comparing the new library with NimbleOptions is giving homework to the reader so I am going to skip it and just use the former instead.
Popular in Announcing
Other popular topics
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
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









