Configure Type inheritance

Inheritance answers one question: what kind of thing is this? If you track colleagues as Employee Objects with a parent Type of Person, every Employee gets all of Person’s properties and relations, and a search for People includes your Employees too.

Each Type has exactly one parent, and every Type ultimately traces back to the root Type, Note. The hierarchy is a tree, so there’s never a question of which of two parents a property came from.

Choose a parent while creating a Type

1. Start a new Type from Add object type (see Create a Type).
2. On the Identity step, open Parent type and select the most specific Type that every future Object genuinely is.
3. Check the Effective schema preview. It labels where each property comes from, so you don’t recreate one the parent already supplies.

Note

The parent is fixed when the Type is created. This keeps the taxonomy stable for every Object and query that relies on it.

Review a Type’s inheritance

Open Object type settings → Inheritance. The section shows the inheritance chain, the parent, and the Inherited & mixed-in properties. Those properties are edited on the Type or Mixin that defines them, not here.

To build a more specific kind of an existing Type, choose Create a subtype of Type name. The new-Type wizard opens with that Type preselected as the parent.

What descendants inherit

A child Type receives its parent’s properties, relations, and Mixins, and so on up the chain. For example, with Person → Employee:

• a department property added to Employee exists only on Employees;
• an email property added to Person appears on every Person and every Employee;
• type:Person in a query returns People and Employees;
• a Collection scoped to Person accepts Employees as members.

A child can’t add a property whose name collides with an inherited one; Lar reports the conflict when you create or edit the Type.

When inheritance is the wrong tool

Don’t choose a parent just to borrow fields. If Project and Invoice both need a due date, neither is a kind of the other: attach a shared Mixin instead.

Likewise, use a relation for ownership or association. A Book has an author; it isn’t a kind of author.

Why there’s only one parent

Multiple parents look flexible until two of them disagree about a property, for example one parent defines rating as a number and another as a label. Lar avoids that ambiguity by design: the single-parent tree says what a thing is, Mixins add shared structure, and relations connect Objects.

Next: Mixins.