Re:Flecs – A fast entity component system for C and C++
by mananaysiempre on Friday April 07, 2023 @06:41PM
(#35488006)
Do you have any references you could give on this subject? I think I have a fair idea of all the object systems you listed (and a couple of others), but I understand very little about ECS. And every time I read about ECS I feel like it should be expressible as some flavour of OOP much as you say here, but I struggle to express that in a concrete manner.
In particular, keeping a single object’s state in several separate memory regions seems atypical (prototypes—or Self’s “traits objects”—are usually stateless even if they don’t have to be); and I can’t think of any way to map iteration over all objects that have parts of a specific kind, often mentioned in expositions of ECS, to a conventional OOP concept (seems relational if anything).
There are hints (and needs) in ECS systems of post-hoc/runtime Prototypical inheritance rather than pre-hoc/design time Class based construction.
There are facets of ECS that resemble concepts like mixins and pattern matching and multi-dispatch and message passing rather than "pure" "C++ VTABLE" dispatch.
Some of these things arise more naturally in other branches of the OOP family tree: the Common Lisp Object System can do some of these things out of the box; Smalltalk and its descendants (even Objective-C) were easier to mold to ECS-like configurations; IO had interesting things to say about this style of OOP; even much-maligned JS' "strange" branch of Prototypical OOP has a bunch of low-level tools that make ECS "less of a need" in JS because there are ways to do them more "naturally".
Certainly, though, in C++ and closer-related derivatives (even Java and C#) ECS isn't as naturally a pattern, which is why it often has need for strong "frameworks" and why there are often multiple, competing ones to pick from.