[pjmlp]

OOP is not inheritance, just one possible trait among OOP implementations, just like FP isn't Haskell.

Component programming with interface separated from state is exactly what Objective-C protocols, COM, VBX, SOM, Component Pascal were all about.

Those that promote ECS as not being OOP 99% of the times never read books like the one I linked on my comment.

Instead they reference a talk done at GDC by one of the very first engines that made it well known to those that never read CS papers or books.

[setr]

Interfaces/protocols aren’t really the same though. An interface defines capabilities for an object; the capabilities are directly associated with the type.

In ECS (where Components are a bag of data, and systems handle all logic/operations), and like a DB, the object is defined by an id and its relations; from the relations, you can derive available capabilities.

That is, an object tells you what it can do. In a DB, what it can do tells you the object.

You can create the same system with interfaces by simply ignoring the methods part of it, and keeping the data part, but associating data with capabilities is pretty much the defining difference between objects and structs.

More importantly from an architectural perspective, in ECS the logic isn’t associated with the object, it’s associated with a system that takes the object as input. The system is shared across all objects. The object (entity) for ECS is little more than an id and some relations.

An ECS very directly corresponds to an RDBMS. To call it OOP is to deny the ORM’s classic Object-Relational mismatch.

[pjmlp]

An interface in a component object model can be made only of properties.

Secondly most languages with OOP support aren't Smalltalk/Java, rather multi-paradigm, e.g. Objective-C, Component Pascal, C++, Delphi, Python, among others when Component Programming came into CS papers for the first time.

To argue that Component Programming is not OOP is just religious hate that shows lack of knowledge regarding CS literature.

[setr]

> An interface in a component object model can be made only of properties.

Yes, I addressed this case. It can be done, but it rips the “object” out of it — you’re no longer sensibly organizing things under an “OOP” paradigm, but something else altogether. You’re quite directly reducing the “object” to a struct.

> Secondly most languages with OOP support aren't Smalltalk/Java, rather multi-paradigm, e.g. Objective-C, Component Pascal, C++, Delphi, Python, among others when Component Programming came into CS papers for the first time.

That’s fine, but doesn’t really support a case that it’s an “OOP” architecture/mindset/organization. In fact, that rather undermines your case..? A language that isn’t interesting in being purely OOP (is anyone?) is happy to introduce an arbitrary construct is not an argument that the construct must therefore be “OOP”

> To argue that Component Programming is not OOP is just religious hate that shows lack of knowledge regarding CS literature.

It’d be more about diluting the term into nothingness — closures are a poor man’s objects, and objects are a poor man’s closures. It’s technically true, but it wouldn’t be useful to go ahead and describe all functional programming as “OOP”, because the main interest in defining the terms is to indicate architectural and logical flow/patterns one would expect under such a paradigm/organization.

Interfaces and classes with no defined methods looks and feels much closer to Haskell and C than it does C#, python and smalltalk.

OOP is not a technical definition. It’s an organizational strategy, and the term itself is just a marker on a continuum. Everything is OOP, and nothing is, just as all things are Turing machines. But that’s not the point.

[pjmlp]

That is surely the point, everything else is religious hate without any technical substance.

Apparently me in the mid-90's porting an particle engine from Objective-C NeXT into Visual C++ using COM on Windows, with a component based architecture, did not happen.

[setr]

I’m not clear — did you just ignore everything I wrote and mindlessly restate your claim, in a manner akin to one undergoing a fit of religious fervor?

[shkkmo]

> OOP is not inheritance, just one possible trait among OOP implementations, just like FP isn't Haskell.

I didn't say it was. The key par was "state is managed seperately from logic."

> Component programming with interface separated from state

There is no such things as interfaces in ECS. Interfaces are a way of describing how state is bundled with logic. ECS does not do that.

> Those that promote ECS as not being OOP 99% of the times never read books like the one I linked on my comment.

I'll admit that I have not read that book. Your condescending appeal to authority here doesn't actually promote conversation.

Please, tell me what the "objects" are in ECS or what else qualifies it as OOP?

[pjmlp]

There are no "objects" in ECS, rather Components as the name clearly states.

Funny why do most ECS frameworks use interfaces/traits/pure virtual classes/static polymorphism then, since they don't exist according to you?

https://github.com/skypjack/entt

Component orientend programming is a subset of OOP, as for why that is, I provided a book, feel free to educate yourself.

More CS papers are available on demand.

[jhgb]

> I didn't say it was. The key par was "state is managed seperately from logic."

But state is managed separately from logic pretty much anywhere where you don't store lambdas as fields of structs.