ECS is a kind of Data Oriented Programming / Data Oriented Design. In Data Oriented Programming data and code are separated (no encapsulation). This makes changes much easier to do and helps a lot with managing state.

For what it's worth, I'm not aware of anyone who believes inheritance "ontologies" was a good idea, nowadays. Interfaces sure, but composition is just better for this reason. ECS is a formalization of that, and probably even perpetuated the idea, but it's everywhere I look now.

> 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.

Since ~2007: https://blog.berniesumption.com/software/inheritance-is-evil...

Jedi "has dark powers", not Jedi "is dark jedi".

That way R2D2 can "has dark powers", as well as can "has light powers".

Sounds like it would have the same problems during refactoring if many different entities relied on the same data. You would have to make sure none of the entities’ behavior changes when you’re modifying your data. It also sounds very verbose where you have to compose each entity all over again instead of inheriting and adding an additional property. But that being said, I would take being verbose over weird hidden layers of abstraction any day.

That just sounds like OOP but without subclassing.

I asked ChatGPT 4 for an explanation and came up with this analogy,

Imagine all in-game characters have their data in a database. The database might have one or more tables representing an objects ID or another reference, its position, its health points, and image data representing how to draw the object. These three things are "components" and the IDs and references are "entities."

A system is anything that manipulates one of these components. Thus, a function that manipulates a component is a system.