A sort of inheritance for struct?

My suggestion would be to just create 4 structs one for each type of Post. You could avoid the duplication by using some macros but it may end up making the code hard to understand.

defmodule Post do
  @base_fields [id: 1, type: "Post"]
  defmacro __using__(fields) do
    fields = @base_fields ++ fields
    quote do
      defstruct unquote(fields)
    end
  end
end

defmodule Video do
  use Post, caption: "This is the best video"
end

defmodule Test do
  def test do
    IO.inspect %Video{}
  end
end

Test.test
#=> prints %Video{caption: "This is the best video", id: 1, type: "Post"}

Thanks @minhajuddin, this was also my idea. I posted my question to discover any alternatives (if there are any).
So far, the only solutions that I can think of are:

• copy pasting the Post defstruct (and @type and doc) as many times as there are subtypes
• Going the Plug.Conn way: declare all properties of the subtypes in the Post type
• defining the N types and use a macro to avoid copy pasting

If there is another approach, I’d be curious to know about it. A more experienced functional programmer could certainly explain how to approach this problem.

Assuming that a post is only a certain type (Text-only, Video-Only, etc.), then I would make a post struct with a post_type argument akin to:

defmodule Post do
  defstruct blog_name: "", id: -1, post_url: "", whatever_else: :blah, post_body: %{}
end

Where :post_body can be any of a set of other structs, such as:

defmodule Post.Text do
  defstruct title: "", body: ""
end

defmodule Post.Photo do
  defstruct photots: [], caption: "", width: -1, height: -1
end

# etc...

If however a post can contain multiple things, say you could have one that has text, video, more text, then a link then just make post_body be a list in the order they should appear.

Would not be hard to map to a database either and you can match on the post_body struct types too.

You can always invert it and have the Post be a Post.Info that is an info subtype of any of the other types too:

defmodule Post.Info do
  defstruct blog_name: "", id: -1, post_url: "", whatever_else: :blah
end

defmodule Post.Text do
  defstruct title: "", body: "", info: %Post.Info{}
end

defmodule Post.Photo do
  defstruct photots: [], caption: "", width: -1, height: -1, info: %Post.Info{}
end

# etc...

Depends on which way makes more sense given the data.

On a side-note, I hate how plug has a lot of ‘built-in keys’, I wish it were a generic map that we could define our own new plug pipelines over that are not webserver oriented without building our own plug type, you could always use a webserver plug struct as a value of a webserver key or something… >.>

oh cool I don’t know why I didn’t think of composing my structs, and I like that they can be composed in both way:

• Post type composed of properties + one sub type
• Specific types composed of their properties + the common type

Thanks, now I need to figure out which solution to pick.

I am a huge proponent of composition over God-Objects and OO-style inheritance both. I use a lot of ECS and Data-Flow designs as well as they are related.

FWIW, one rule of thumb coming from OO land to Elixir Land.

Everytime you start thinking you need to “inherit” something, instead think about composing something.

Actually that rule works pretty well in OO Land as well.

Thank you very much. I came across this thread while searching for “elixir composing structs.” This is exactly what I was hoping people would recommend.