The Big OOPs: Anatomy of a Thirty-Five Year Mistake

No. His definition is exactly what people are taught OOP is. It is what I was taught, it is what I have seen taught, it is what I see people mean when they say they are doing OOP.

> Perhaps his definition needs a different name.

No. Your definition needs a different name. Polymorphic functions are not OOP. If you give someone standard Julia code, a language entirely built around polymorphic functions, they would tell you that it is a lot of things, except nobody would call it OOP.

Importantly polymorphic functions work without class hierarchies. And calling anything without class hierarchies "OOP" is insane.

When it comes to organising your code in an ECS-esque fashion, it is much closer to normalising a database except you are organising your structs instead of tables.

With databases, you create tables. You would have an Entity table that stores a unique Id, and tables that represent each Component.. which there would be a EntityId key, etc.

Also, each table is representative of a basic array. It is also about knowing a good design for memory allocation, rather than 'new' or 'delete' in typical OOP fashion. Maybe you can reason the memory needed on startup. Of course, this depends on the type of game.. or business application.

An 'Entity' is useless on its own. It can have many different behaviours or traits. Maybe, if referring to games, you can have an entity that:- has physics, is collidable, is visible, etc.

Each of these can be treated as a 'Component' holding data relevant to it.

Then you have a 'System' which can be a collection of functions to initialise the system, shutdown the system, update the system, or fetch the component record for that entity, etc.. all of which manipulates the data inside the Component.

Some Components may even require data from other Components, which you would communicate calling the system methods.

You can create high level functions for creating each Entity. Of course, this is a very simplified take :-

  var entity1 = create_player(1)
  var boss1 = create_boss1()

  function create_player(int player_no) {
    var eid = create_entity();
    physics_add(eid);             // add to physics system
    collision_add(eid);           // add to collision system
    health_add(eid, 1.0);         // add health/damage set to 1.0
    input_add(eid, player_no);    // input setup - more than 1 player?
    camera_set(eid, player_no);   // camera setup - support split screen?

    return eid;
  }

  function create_boss1() {
    var eid = create_entity();
    physics_add(eid);
    health_add(eid, 4.0)          // 4x more than player
    collision_add(eid);
    ai_add(eid, speed: 0.6, intelligence: 0.6);  // generic AI for all

    return eid;
  }

What the talk is about compile time (and maybe execution time in the case of python) hierarchies being structured as a mapping of real objects. This is how I was taught OOP and this is what people are recognizing as "OOP".

>So for the anti-OOP folks out there using languages like Python as an example,

Just because a language associates data with functions, does not mean that every program hierarchy has to map onto a real world relationship.

Why are you even commenting on this with your nonsense? Do you really think that if someone is complaining about OOP they are complaining that data types store functions for operating on that data? Has literally anyone ever complained about that?