> I'm not aware of anyone who believes inheritance "ontologies" was a good idea, nowadays.

like, all of anything you could program, ever? for any purpose?

Inheritance works for essential things and composition for accidental things. Use both together to get the full Aristotelian deal.

Except of course for all the ontologies in your language's standard library that you don't even notice. Your IO hierarchy, exception hierarchy, your collections hierarchy.

As long as you don't kingdom of nouns everything any repeat the mantra: "classes are just interfaces with code reuse" you'll be fine.

This is factually correct, but misses the point I was trying to make. I'll fall on my sword there.

What I mean is: For library developers, inheriting an interface makes some sense. But throwing in an ontology that is meant to mimic human-like classification (esp just for the sake of it) is a disaster in all the code I've seen. There really isn't any reason for a Shape: Circle hierarchy. The better abstraction is around what can be done: a PrintableList<Point>, or whatever.

std:: takes the second approach (Type trait-like interface_-level decisions. There was (for a time) a huge push for the first approach of "is-a" relationships which makes zero sense almost any time.

IMHO ECS is a sane "has-a" relationship which is effectively a redo of "is-a" interface-level interactions, b/c each entity "has-a" list of objects that form it's interface with the system.

You're correct here. I see this as a - still too common[0] - lack of understanding of what classification/ontology/taxonomy is. Categories are made for humans. They're arbitrary and judged only by one thing - are they good enough for the problem being solved. In this sense, reflecting a real-life ontology in your code is usually doing things backwards - it's the code that should invent it's own ontology that's maximally convenient for the problem being solved[1]. Real-life ontologies all have their purposes, but they usually don't include making it easier for you to write software.

--

[0] - Is tomato a fruit or a veggie? Is a whale a fish or a mammal? Etc. The answer to that is just "either, none, whatever - it's you who are confusing culinary, economic and genetic taxonomies".

[1] - Which is some combination of code thinking and domain thinking. It's never just purely one of them.