A sort of inheritance for struct?

Questions / Help
1

Hi,

I would like to get recommendations on how to approach this problem.

I’m writing a client for an API (tumblr). For example, this API let me retrieve all the posts for a given tumblr blog.

Yet, those posts can be of different types such as text, photo, video, audio, … Any post will have one of these type but they all share some common properties like a date, the number of likes, etc. Given their nature, they also have specific properties. Let’s say that audio and video posts have a duration property but text posts don’t.

The way you know that a post is of type X is by checking the type that is one of the common properties.

Until today, I focused on the properties in common between all types and I created a Post struct to represent them. Now I would like to have a way to represent all specific types and ideally without copy-pasting the current Post struct everywhere.

What are my options to represent all types too ?

Tumblr API / Posts

EDIT: If I define all properties of all post types into the one I currently have, this is what I get:

@type t :: %MODULE{
blog_name: String.t,
id: non_neg_integer,
post_url: String.t,
type: String.t,
timestamp: non_neg_integer,
date: String.t,
format: String.t,
reblog_key: String.t,
tags: [String.t],
bookmarklet: boolean,
mobile: boolean,
source_url: String.t, #MOVE TO QUOTE POSTS? see “Notes” column in docs
source_title: String.t, #MOVE TO QUOTE POSTS?
liked: boolean,
state: String.t,
#FOR TEXT POSTS
title: String.t,
body: String.t,
#FOR PHOTO POSTS
photos: , #todo: list of photos objects
caption: String.t,
width: number(),
height: number(),
#FOR QUOTE POSTS
text: String.t,
source: String.t,
#FOR LINK POSTS
title: String.t, #fixme: already defined for text posts
url: String.t,
author: String.t,
excerpt: String.t,
publisher: String.t,
photos: , #fixme: also defined for photo posts
description: String.t,
#FOR CHAT POSTS
title: String.t, #fixme: also defined for link and text posts
body: String.t, #fixme: also defined for text posts
dialogue: , #todo: define a type for the contained objects
#FOR AUDIO POSTS
caption: String.t, #fixme: also defined for photo posts
player: String.t,
plays: non_neg_integer,
album_art: String.t,
artist: String.t,
album: String.t,
track_name: String.t,
track_number: non_neg_integer,
year: non_neg_integer,
#FOR VIDEO POSTS
caption: String.t, #fixme: also defined for audio and photo posts
player: , #fixme: also defined for audio posts AND IT’S A DIFFERENT TYPE!!!
#FOR ANSWERS POSTS
asking_name: String.t,
asking_url: String.t,
question: String.t,
answer: String.t

1 Like
2

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

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.

4

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… >.>

8 Likes
5

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.

6

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. :slight_smile:

1 Like
7

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.

7 Likes
8

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.

2 Likes