The Entity-Component system is not really about composition over inheritance, mostly because "Inheritance vs. composition" is not an either-or choice, but also a little bit because Entity-Component is not really even the best way to perform composition, if greater composability is your only goal.
The choice of inheritance vs. composition is not a dichotomy, it's a spectrum. There are certain properties of your program that are better modeled through inheritance, and others that are better modeled through composition. You end up using both in the vast majority of systems.
Classical object-oriented GUI frameworks have a Button class that inherits through a chain of classes that add greater refinement of behavior. See [0]: System.Object -> Component -> Control -> ButtonBase -> Button.
But you don't create such a hierarchy for something like a login form. A login form will inherit from Form [1] and use composition of subcontrols to create its behavior. You'll have a few textbox controls, a few labels, and a couple of buttons composed with the login form.
And neither is an Entity-Component system really all that great of a composition system. You end up having to query the system for cross dependencies at runtime a lot, as there are no compile-time, static guarantees that any particular component will exist. Something like Inversion of Control with Dependency Injection can give you a better workflow for getting dependent components together in the same place.
Incidentally, building a project in an Entity-Component system (or any composition-based system) does not prevent one from being able to utilize inheritance, either. I'm not even aware of any composition systems that don't use inheritance heavily, actually. For example, Unity's ScrollView [2] component has the chain System.Object -> CallbackEventHandler -> Focusable -> VisualElement -> ScrollView.
An Entity-Component system is really much more about creating ad-hoc objects. Game design is notoriously finnicky. There is no schema or "shape" of fun. You tweak and reorganize and tear apart and recombine things until it just "feels" right. So Entity-Component makes it possible to create and compose objects on the fly, with fairly reasonable performance.
So these statements like "I turned away from inheritance 20 years ago and I'm now all about composition", they just don't make sense. "Inheritance vs. Composition" is not something you think about at the application level. It's something you think about at the functional unit level, and make the choice separately for every functional unit.
The choice of inheritance vs. composition is not a dichotomy, it's a spectrum. There are certain properties of your program that are better modeled through inheritance, and others that are better modeled through composition. You end up using both in the vast majority of systems.
Classical object-oriented GUI frameworks have a Button class that inherits through a chain of classes that add greater refinement of behavior. See [0]: System.Object -> Component -> Control -> ButtonBase -> Button.
But you don't create such a hierarchy for something like a login form. A login form will inherit from Form [1] and use composition of subcontrols to create its behavior. You'll have a few textbox controls, a few labels, and a couple of buttons composed with the login form.
And neither is an Entity-Component system really all that great of a composition system. You end up having to query the system for cross dependencies at runtime a lot, as there are no compile-time, static guarantees that any particular component will exist. Something like Inversion of Control with Dependency Injection can give you a better workflow for getting dependent components together in the same place.
Incidentally, building a project in an Entity-Component system (or any composition-based system) does not prevent one from being able to utilize inheritance, either. I'm not even aware of any composition systems that don't use inheritance heavily, actually. For example, Unity's ScrollView [2] component has the chain System.Object -> CallbackEventHandler -> Focusable -> VisualElement -> ScrollView.
An Entity-Component system is really much more about creating ad-hoc objects. Game design is notoriously finnicky. There is no schema or "shape" of fun. You tweak and reorganize and tear apart and recombine things until it just "feels" right. So Entity-Component makes it possible to create and compose objects on the fly, with fairly reasonable performance.
So these statements like "I turned away from inheritance 20 years ago and I'm now all about composition", they just don't make sense. "Inheritance vs. Composition" is not something you think about at the application level. It's something you think about at the functional unit level, and make the choice separately for every functional unit.
[0] https://docs.microsoft.com/en-us/dotnet/api/system.windows.f...
[1] in WinForms that'd be: System.Object -> Component -> Control -> ScrollableControl -> ContainerControl -> Form
[2] https://docs.unity3d.com/ScriptReference/UIElements.ScrollVi...