Dysfunctional Options Pattern in Go

The problem with options in non-ML languages is that invalid state is unrepresentable[1]. E.g, in Java Option<Integer> can either be null, empty, some with null and some with a number.

To solve this problem, a language have to disallow null/nil as a bottom type and provide nice syntax to initialize types with optional types.

[1]: https://geeklaunch.io/blog/make-invalid-states-unrepresentab...

mmaniac · a year ago

Optional types don't fix this. The problem here is not having default (or named) function arguments. With optionals, you still have to pass every arg explicitly.

Languages with both of these features like Python don't end up using the builder pattern or reinventing it like this author.

ivanjermakov · a year ago

evanmoran · a year ago

I like this write up. Nicely done! One think I have enjoyed doing is using named parameters as the options, but it does require a second struct only for the option parts:

    NewObject(
      required1, 
      required2, 
      &ObjectOptions{
        Option1: “foo”,
        // Option2 skipped
        Option3: “bar”,
    })

I can see the merits of both (two structs is tedious, for sure), but I wanted to share in case others had thoughts or alternate ideas!

abahlo · a year ago

Isn’t this just the builder pattern without Build()?

rednafi · a year ago

The conclusion mentions that.

iambvk · a year ago

What are the downsides of just adding new methods on the `Config` structure?

    func (c *Config) WithFizz(...) {...}

    func (c *Config) WithBazz(...) {...}

Isn't it essentially doing exactly that? The only difference is that it returns a pointer to the struct from each method. The advantange of doing that is it allows you to compose it as such `WithFizz(...).WithBazz(...)`.

If you don't need the composition, you can just add the methods as above and call it a day.

tail_exchange · a year ago

Looks cleaner and simpler. I like this pattern!