[echelon]

There is no benefit to the "tree of life" single inheritance [1].

What you want to reach for to achieve compositional behavior or polymorphism are type classes, traits, and interfaces. They attach methods to data without the silly "Cat is an Animal, Dog is an Animal" cladistic design buffoonery.

There's nothing wrong with OO, except for inheritance-based OO.

[1] Don't get me started on multiple inheritance. Instead of solving problems, they invented them.

[butlike]

What about a situation where you have an ECS, and if it has say, LifeComponent(), ReproductionComponent(), it can be identified as an Organism (as opposed to say a Crate). Now, you can have inheritance off of that, a composition can be identified as an Orangutan, or a Human, but only if it was an Organism. The Organism is basically a memoization of Life and Reproduction components on the Orangutan.

Now, A human can create a child, but only if the parent object was a "Human." Am I thinking about this in the wrong way?

[norir]

Yes. I hadn't heard the term tree of life inheritance, but that is the heart of the problem. I think this could be somewhat mitigated by banning access to non-abstract parent methods and all grandparent methods (as well as all relations that aren't directly reachable by going up the tree). But at that point you might as well just use composition anyway.

[butlike]

GreatGrandparent->setCancerChancePercent(10);

Grandparent->mutateCancerChancePercent("+|-", 3);

Parent

Child

By banning access to GreatGrandparent's getCancerChancePercent(); method, I won't know what the starting chance was, which will make it harder to determine nature vs. nurture. Isn't that what ancestry and genome mapping is doing? Going back up the tree?