Inheritance

Inheritance is Lar’s first composition axis, and it answers exactly one question: what fundamentally IS this Object?

• Every Type declares at most one parent Type via extends.
• All Types trace back to a single root, Note.
• The tree is diamond-free by construction — a Type cannot have two parents.

Note
└── Person
    └── Employee
└── CreativeWork
    ├── Book
    └── Article

An Employee inherits every property and relation Person declares, plus its own. Query type:Person and you get Person and every descendant Type, because the IS-A relationship is real, not a label.

Why single inheritance, deliberately

Multi-inheritance taxonomies look flexible until two parents disagree about a property’s shape — the diamond problem. Lar keeps the IS-A tree single-parent on purpose, and instead gives cross-cutting structure two other mechanisms that don’t fight inheritance for the same job:

• Need a bundle of properties shared across otherwise-unrelated Types (e.g. “things with a due date”)? That’s a Mixin, not a second parent.
• Need to organize one Object differently? Use a tag, relation, or a property on that Object.

This was not the original design — an early version of Lar used ad-hoc multi-inheritance and it broke down in exactly the way described above. Splitting the three axes apart, each with a single well-defined job, is what actually holds up under real use cases.