Defining a new (custom) type - best practices? Cleaner code?

Here’s a simple type for a piece of historical stock info:

defmodule DayRecord do
  @enforce_keys [:date, :close, :high, :low, :open]
  defstruct date: ~D[1900-01-01], close: 0, high: 0, low: 0, open: 0
  @type t :: %__MODULE__{date: Date.t, close: Float, high: Float, low: Float, open: Float}
end

I’m sure there’s more I can add, but I’m already a little unhappy with the redundancy and mix of different DSLs and implementation details.

Am I going down the right path?

I’ve seen a Hex package that wraps some of this up. Is there any traction around a certain way of removing the boilerplate? Maybe continuing defstruct's example, and making a higher level macro?

First thought: enforce_keys and default values are at cross-purposes; the defaults supply a value for when the key isn’t passed to %{}, but enforce_keys requires that the key be passed. Note that enforce_keys is NOT a “not null” constraint - it’s completely valid to pass nil for an enforced key.

If you have some fields that should always be passed but others that should be defaulted, you could extract some of the duplication:

defmodule StructDemo do
  @enforce_keys [:first_name, :last_name]
  @optional_keys [age: 0, heads: 1]
  defstruct @enforce_keys ++ @optional_keys
end

Usage:

iex(2)> %StructDemo{first_name: "Bob", last_name: "Dobbs"}
%StructDemo{age: 0, first_name: "Bob", heads: 1, last_name: "Dobbs"}

iex(3)> %StructDemo{first_name: "Prince"}
** (ArgumentError) the following keys must also be given when building struct StructDemo: [:last_name]
    expanding struct: StructDemo.__struct__/1
    iex:3: (file)

iex(3)> %StructDemo{first_name: "Nobody", last_name: nil}
%StructDemo{age: 0, first_name: "Nobody", heads: 1, last_name: nil}
5 Likes

Not OP, but that’s straight up beautiful. Thank you!

2 Likes