Multi-Type Vs. Inheritance

[Alejandro]

Overview

The two features that create the most excitement to me are Multi-types and Inheritance, two features hightly interrelated.

In a comment by @ignatovv, he said that the Team wants to introduce Multi-Types and in the last Townhall a dev talked about working in some small feature requests as extendable objects after the open beta (iirc). In case the team had to prioritize one of these, which one would you choose?

---

Inheritance:

Inheritance, a widely recognized principle in software development and data modeling, involves creating relationships between different types of data by inheriting attributes and behaviors from a parent type. In the context of Anytype, inheritance would allow us to define a base data model with shared relations, which can then be inherited by other types.

Multi-types:

Contrasting with inheritance, multi-types would provide a dynamic and flexible approach to data modeling within Anytype. Multi-types would allow objects to possess multiple types simultaneously.

---

Benefits &/or Advantages

Inheritance

1. Reusability: If you have to create a new type that can already be classified under an existing one, you don’t have to create it from the ground up, you can just extend that type and all its relations will the part of your new type.
2. Extensibility: If you forgot to add a relation to some types, but said types already extend another one, you don’t have to add them one by one, you can just add them to the parent type and the extended types will have that new relation.
3. Simplicity: In comparison to Multi-types, you only need a single type instead of having to add multiple ones (Inheritance: Director, Writer, Friend, Coworker… Multi-Type: Human & Director, Human & Writer, Human & Friend, Human & Coworker…)
4. Nesting/Navigation: Inheritance creates a natural navigation of sets.
   
   

Multi-Types

1. Flexibility: In comparison to Inheritance, Multi-Types would allow you to add the multiple roles that an object can have instead of having to deal with a single one. (Human can be a director, but can be a friend, and a writer and a coworker at the same time).
2. Extensibility: Not as flawless as inheritance, but due to the redudancy it creates (Human & Director, Human & Writer), in theory same as inheritance, you only need to add a single relation in this use case.

---

Disadvantages, Trade-offs &/or Considerations

Inheritance:

1. Design: I think that inheritance must have a re-design in the Set View to show the inherited types.
   

   

2. Flexibility: Compared to Multi-Types, Inheritance is not as flexible, it forces you to have a single type (Director OR Actor)

Multi-Types:

1. Redudancy: You need to repeat a lot to create the same structure as Inheritance (Human + Director, Media + Images) and it’s only at the object level, not the navigation as Inheritance.
2. Conflicts?: If I create a type with a basic layout and if for whatever reason I add another type with action layout for example, what should happen? Should Multi-Types have a diferent page for each type?
   
   

---

Conclusion

• I think that I like the idea of inheritance better, I find the idea more apealing and I think that a lot of people can more easily resonate with this.
• The flexibility is one of the biggest trade-offs that inheritance has but, besides Human with its multiple roles/professions… Which real use cases would this extended flexibility has?
• Ideally inheritance could and should allow multiple nesting.
  • Human > Important > Family > Partner
  • Human > Important > Friend
  • Human > Work > Coworker
  • Human > Work > Client
• I think of workflows when the parent type can be consider as a kind of inbox for later classification. I could create Humans in the Work type and use it as my Prospects and once I understand their real role, I could move them to their new type as Clients , Providers …

---

IMPORTANT

One feature doesn’t exclude the other one, both of them can co-exist. This is just under the idea that the team had to choose which one to prioritize because of limited development resources. And I would like to read what you think about any of this approaches to Anytype’s future.

Thanks for reading.

---

[isle9]

Great post. In the long term ideally, both would be implemented.
I would prefer inheritance to come first, but it seems like the team already has some plans for multi-types since they said in the last Townhall that they won’t to make types work more like tags.

[qualquertipo]

Now that’s a post. You got my like

[Tamalika]

I think, as Anytype’s structure stands right now, inheritance may be better suited to be apply on “relations” rather than on type. For example,
The Batman is a “type” of media. It’s main “relations” is

• Genre : movie
  • Film industry : Hollywood
  • Sub-genre : Superhero movie
• Director : (object type relation) Matt Reeves

Then again for the object named Matt Reeves, the object type is Human.
Relation :
Occupation : Movie director
Movie industry : Hollywood
Movies : (another object type relation) The Batman.

We can then use multi-type feature to collect all the media and human types together.

Then sort them to show Human if Occupation is director.
Then sort Media by

• if genre is movie and
• sub-genre is superhero movie and
• film industriy is Hollywood.

Then we can find all Hollywood superhero movies with their directors.
I hope I made some sense.
This is an awesome discussion. Thanks.

[kerbless]

Lovely post!

I really like both ideas and I hope to see at least one implemented.

Another thing that I’d like to add to the discussion is the fact that as of now Relations are only loosely related to a “Type” (you can edit Object Relations independently from it’s Type).

I already said somewhere that my take on this is to maintain maximum flexibility while advertising only a more streamlined use of objects.

This is relevant because how we define an object (a set of relations + icon + body made of blocks?) has important repercussions on designing features that rely on the “object philosophy” like this one.

[Tamalika]

So true. I would vote for every thing is an object idea in the manner that,

• A block of test should be considered a text-block type object
• A word a text type object.
  this way, we can get, what we would traditionally call, a block to block or block to object relation or reference block.
  I have been requesting this from the start.
  Thanks for the awesome discussion.
  Edit : some spelling

[Kerstie]

Great explanation. If I have to choose one to prioritize, I’d go with Multi-Types because my use cases can exist on Multi-Types alone whereas Inheritance, for me, would still feel like an unpolished Type experience because I’d still want to categorize some objects under different Parent Types. I also like the simplicity of ‘tagging’ as you go along, as I wouldn’t have to decide on Type hierarchy beforehand.