ADR: Normalize the Functional Options pattern used within the monorepo

[jrschumacher]

Implementation of the Function Options pattern has diverged

Problem

As the Functional Options pattern has been implemented throughout the monorepo, the pattern is starting to vary. We need to normalize on a pattern so that we can reduce cognitive load.

Ref: https://github.com/opentdf/platform/pull/179#discussion_r1502726661

References

• https://github.com/tmrts/go-patterns/blob/master/idiom/functional-options.md
• https://commandcenter.blogspot.com/2014/01/self-referential-functions-and-design.html

Solution

• choose a pattern
• implement common types

Options

Functional approach

• 🟢 Avoid nil-pointers
• 🟢 Immutable
• 🟢 Stay on the stack
• 🟡 Extra line

If you just pass everything by value, you always run on the stack and don’t have to incur the overhead of garbage collection. (The GC will still run by default. But having less on the heap will make the GC have less work to do). ^1

func WithSomething(v string) (func(c Opts) Opts, error) {
    if v == "" {
        return nil, fmt.Errorf("value shouldn't be empty")
    }
    return func(c Opts) Opts {
        c.Value = v
        return c
    }, nil
}

Object oriented / pointer approach

• 🟢 Reduced number of lines
• 🟡 Possible performance improvement
• 🔴 Requires Escape Analysis^2
• 🔴 Possible nil-pointers
• 🔴 Mutable data structures

func WithSomethingElse(v string) (func(c *Opts), error) {
    if v == "" {
        return nil, fmt.Errorf("value shouldn't be empty")
    }
    return func(c *Opts) {
        c.Value = v
    }, nil
}

[jrschumacher]

@dmihalcik-virtru @strantalis any feedback on this and can we make a decision?

[strantalis]

@jrschumacher I have no strong opinions here. I am open to trying option 1 and if we need to change we can always do that.