bopjesvla

bopjesvla

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.

Showing Posts 1 to 6

lpil

lpil

Creator of Gleam

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 :slight_smile:

Phillipp

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

Qqwy

TypeCheck Core Team

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:

defmodule OptionsExample do
  def foo(normal, arguments) do
    foo(normal, arguments, some_option: true)
  end

  def foo(normal, arguments, some_option: some_option) do
     # ...
     IO.inspect({normal, arguments, some_option})
  end
end

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:

** (FunctionClauseError) no function clause matching in OptionsExample.foo/3    
    
    The following arguments were given to OptionsExample.foo/3:
    
        # 1
        10
    
        # 2
        20
    
        # 3
        [unexistent: 42]
    
    Attempted function clauses (showing 1 out of 1):
    
        def foo(normal, arguments, [some_option: some_option])

Writing code like this is already a very lightweight way to create the behaviour you are suggesting.

bopjesvla

bopjesvla OP

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 def to deal with parsing options:

  def foo(normal, arguments, !some_option = 5, !other_option = 3) do
     # ...
     IO.inspect({normal, arguments, some_option})
  end

But I think the option! macro I suggested would be sufficient.

Qqwy

Qqwy

TypeCheck Core Team

I stand corrected. :slightly_smiling_face:

slashdotdash

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.

This library allows you to validate options based on a definition. A definition is a keyword list specifying how the options you want to validate should look like:

definition = [
  connections: [
    type: :non_neg_integer,
    default: 5
  ],
  url: [
    type: :string,
    required: true
  ]
]

Now you can validate options through NimbleOptions.validate/2:

options = [url: "https://example.com"]

NimbleOptions.validate(options, definition)
#=> {:ok, [url: "https://example.com", connections: 5]}

If the options don’t match the definition, an error is returned:

NimbleOptions.validate([connections: 3], schema)
#=> {:error, "required option :url not found, received options: [:connections]"}
— All posts loaded —

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 94592 917
New
cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
caslu
I want to open this thread for you all to discuss and help those who really like Ash but are still hesitant to use it in a real project. ...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
heathen
Quite interesting article Google brought me. Didn’t find any mentions about it here. What do you think in general? Would you use togethe...
New
marciol
It would be helpful to have a list of companies worldwide that hire engineers without prior experience in Elixir. Often, it can be quite ...
New
durvia
Anyone running long-lived stateful processes on BEAM? We’re building an AI agent runtime and would love to compare notes. We’re a small ...
New

Other Trending Topics Top

marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge &amp; Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
Aludel - LLM Evaluation Workbench Aludel is an embeddable Phoenix LiveView dashboard for evaluating and comparing LLM prompts across mult...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews