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

Chat / Discussions
,
1

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?

2

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}
6 Likes
3

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

2 Likes
4

An alternative you can consider also is using Ecto (note you don’t need ecto_sql here either). In that case you can create an embedded schema like so:

defmodule DayRecord do
  use Ecto.Schema

  embedded_schema do
    field(:date, :date)
    field(:close, :decimal)
    field(:high, :decimal)
    field(:low, :decimal)
    field(:open, :decimal)
  end
end

As already mention enforcing the keys then adding defaults is a bit redundant, but if you want to add defaults you can in Ecto too:

defmodule DayRecord do
  use Ecto.Schema

  embedded_schema do
    field(:date, :date)
    field(:close, :decimal)
    field(:high, :decimal)
    field(:low, :decimal)
    field(:open, :decimal, default: Decimal.new(0))
  end
end

To me this makes it perfectly clear the types of each field. Then benefit then is you can use changesets and validations on creation to enforce things like non_null fields etc.

I’ve also been working on a library to give some sugar to this kind of use case called ecto_morph

1 Like