Is your feature request related to a problem? Please describe.
I first came across this in this case:
I created a Type “Abbreviation” to be able to link used abbreviations through my notes.
Then I decided that I also want to have a definition for what that abbreviation stands for - a candidate for a Type “Definition”.
Now I would like to have the possibility to create an Object that is an Abbreviation (with the respective relations), as well as a Definition.
Probably someone already thought about this, but I could’t find it here. Please share your thoughts!
Describe the solution you’d like
I’m not sure about the best solution for this, maybe it relates to different features.
I’d like to discuss this case - also in other possible scenarios.
Describe alternatives you’ve considered
Nothing yet. Open for suggestions.
Additional context
Nothing that seems relevant atm.
The above request would solve type composition. You create a template for abbreviation, in the relation for definition, you add a link to a definition’s template to be used when creating the definition page. So when you create a abbreviation page from the template, a new definition page based on the template linked is created and added to the definition relation of the abbreviation page
There could be other ideas to achieve the same which could be tracked in this request
Okay. I needed quite some time to understand what problem @natrius has , but I think I got it now.
In your suggestion you would create two objects - 1 Abbreviation and 1 Definition. And they are finally linked together and (with the references FR) even created together.
However, I want a single object behave like or even be both: an Abbreviation and a Definition.
Then, when I create a set of Abbreviations, I have them all, as well as all Definitions in a set of Definitions.
Because the important point is that the relations of both Types are part of that new object.
I now found this, where you, @lynxlove, propose sub-typing / inheritance. I guess, this is similar to my proposal.
However, I would say that Composition is superior to Inheritance
Seconding my support of type composition over inheritance - having recently started messing around with the Entity Component System data architecture, I’ve found composition much more flexible than inheritance, as it avoids a lot of the dependency issues.
I also agree with OP that @lynxlove, the creating new blank object thing wouldn’t quite solve the problem of type composition. In a proper composition system your “types” would be a list of relations objects have in common, but rather than having to inherit like subtypes do, they would simply be able to be combined additively on a single object.
For instance, say you have three types:
Human
Actor
Animal
Human and Animal have their own relations set, and Actor has relations like “Awards” “Films Credited”, etc.
With type composition for Robert Downey Jr. you’d create a Human object, and then apply the Actor type to it on top, which would add Actor’s relations. Then if you wanted an Object for, say, Air Buddy, you’d create an Animal Object, and also apply the Actor type to it.
With subtypes, you’d need to create two subtypes - Human-Actor and Animal-Actor.
Type composition at object level certainly makes it easy to create complex types without creating a Type hierarchy tree before. I very much prefer type composition over sub classing for creating objects as well. TBH, I feel what I suggested as Sub-typing is Type composition at the type level and this request is about Type composition at the object level as all we have are relations and no methods on types. I’m okay with my request getting merged with this one since the title of this thread is much more accessible to others and both requests wants multi typed objects
What I’d love is to be able to apply multiple types to both individual objects as well as to types so that one could create a complex type composed of atomic types and use that to create objects in the future. At the type, level, I’d love one more section under layout where one could add types to compose the current type and when a type is added to the list, the relations of that type should be displayed under the relations section of the new type
At the object level, I’d love to have a type composition button near the layout / relations button and once a new type is added the relations list would then have a separate section to list newly added relations from that type
When I understand what you mean, I can change my initial request to reflect that.
Sub-typing is Type composition at the type level and this request is about Type composition at the object level
So, you want to be able to create Types that are composed of other Types and then can also add special relations to it? And that would mean that you (could) still have an object still only of a single Type?
What would be the practical difference of the two ideas? Maybe composite Types enable to keep the object UI easier (still single Type) and pushes the complexity (composition) to the Type interfaces, which are for advanced users only anyway?
If, from the use case perspective the ideas are the same, we should only have one of them implemented, I guess.
I don’t see any problem with both being implemented, personally.
Type composition at the object level allows an object to have multiple types (e.g. Human & Actor)
This is great and flexible, but if you wanted to create lots of (Human+Actor) objects, it might get repetitive having to give each object both types. Allowing type composition at the Type level, as lynxlove suggests, would allow you to create a single (HumanActor) type, which when you create an object of that type, simply applies both types to it.
So adding multiple separate types to the same object (as in this suggestion) is useful if you have a couple of outlier objects which need a weird type combination (e.g. Animal + Actor for Air Buddy), whereas creating a new type which is a combination of multiple types (as in lynxlove’s suggestion) is useful if you have lots of objects with a given type combination (e.g. Human + Actor for Robert Downey Jr.) I think both of these features could exist together in the final product, as they each have their own use cases, and I don’t think their implementations would interfere much with each other.
I wonder if there an official opinion from the developers on this?
I’m facing the same problem, sometime it’s hard to assign one specific type for an object. I really like the type composition idea an think it would solve the problem.
The “official opinion from the developers”. We want to introduce multytypes for objects and go to more flexible system, object type is going to be more of tag + relations + templates.
Not really, roughly this year. It depends on how may use cases it will affect positively and how much activity will be in the community about this feature
I’d like to add another use case for multiple types.
Take a Grape object. It can be a Consumable to keep track of how much you have left, it can be an Ingredient in a recipe, it can be a Task because you need to buy some, and, if you happen to be a wine aficionado, can contain some information about the grape plant.
If Anytype is to act as a second brain, there needs to be only one Grape concept in the graph, not multiple. It might make things messy, but collapsable headers should help quite a bit.
, but I think I got it now.
