Programming against Objective-C protocols, COM interfaces, Component Pascal framework, and so forth.
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.
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.
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.
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.
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.
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?
Funny why do most ECS frameworks use interfaces/traits/pure virtual classes/static polymorphism then, since they don't exist according to you?
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.
But state is managed separately from logic pretty much anywhere where you don't store lambdas as fields of structs.