[glowcoil]

> There has been an explosive growth in component software technologies since the first edition of this classic book was published. The advent of EJB, J2EE, CORBA 3, COM+ and the .NET framework are evidence of a maturing market in component software that goes 'beyond OOP'.

This book seems to be discussing distributed object systems, which is a sense of the word "component" that has little or nothing to do with the sense used by game developers in reference to the ECS architecture. Distributed object systems are designed to enable an object-oriented design philosophy to be used for a system which spans multiple address spaces or machines. The entity-component-system architecture is a methodology for organizing data layout and program functionality, usually within a single address space on a single machine, where the data associated with a given entity is spread across multiple components or subsystems and associated by index relations (much like a relational database), rather than being all grouped together in one place (as encouraged in OOP).

These two concepts (distributed object systems and ECS) are designed to solve different problems, they are generally used in different scenarios, and they apply at different levels of system organization. There is so little resemblance between the two that I have to conclude someone calling them "sides of the same coin" is either completely unfamiliar with one of them or is being deliberately misleading.

[pjmlp]

I also did not state that book was the canonical ECS model, rather that it was one of the first sources to move into discussing components instead of classes.

COM and DirectX aren't distributed object systems, nor Objective-C protocols, for example.

Don't confuse COM with DCOM and COM+.

Then there are the component models based on traits, mixins, patterns, message passing, type classes,... plenty of variants scattered around SIGPLAN and ECOOP papers.

[Rusky]

You are still conflating two totally unrelated things.

The book is one of the first sources to move into discussing "components," as in coding against interfaces/protocols/traits/etc.

ECS deals with "components," as in pieces of data composed using a relational model. This has nothing to do with interfaces or protocols whatsoever! It is practically the opposite thing- working directly with raw data, with no abstraction boundary.

You can't just pattern match on the word "component" and expect it to mean the same thing to everyone.

[pjmlp]

That is the next step, data oriented programming, which many confuse with ECS, as they tend to be used together.

[Rusky]

I am not talking about data oriented programming. With or without that sort of memory layout optimization, ECS "component" still refers to un-abstracted chunks of concrete data rather than interfaces/protocols/etc.

Let's step back even further and consider Unity's pre-DOTS "entities" and "components." These do not take the data oriented approach, are not typically even classified as ECS (e.g. because they lack the System aspect of that design). However, the components are clearly chunks of concrete data (transforms, meshes, rendering parameters, rigid bodies, etc.) rather than interfaces/protocols.

This is the sense in which ECS means "component." That book is not relevant to this sense.

[pjmlp]

A book that I clearly referred it was only one of the first ones that somehow started talking about this, I never stated it was the definition of ECS.

Apparently making the point about how relevant this specific book is, is what matters in this whole thread.

[Rusky]

It didn't start talking about "this." It started talking about something unrelated that you mistook for "this."