OOP is dead, long live OOP

So, I was thinking about my new event driven structure OOP lookalike and how it relates to classic OOP.

In OOP a class is structured like this:
class A {
  public var property1
  public var property2
  public function method1()
  public function method2()
}

Part of the whole point with OOP is that you gotta keep stuff that belongs to class A inside those brackets. you can't just randomly further down in the code add another method3 to A. This is both good and bad. It's good because if you wanna take a look at a class you can find everything associated with that class in the same place. It's bad because it means that things are very set in stone.

In my old Pig-game-style structured code, I would make entities and give the entities a rendering method. Then I would code a loop over all my entities in the World class, calling rendering on each. If one entity needed specific rendering code, I could simply change that Entity's rendering method. The issue turns out that the modifications we can do are always on a per entity basis. Let's say that one entity does not need it's rendering method called. We could either:
a) add a return; statement at line 1 in the entity's rendering method, which is a hack
b) open up the World class and make modifications to how the rendering loop is structured

Both solutions are less than optional. (a) style solutions eat up performance doing nothing and are often not flexible enough, and (b) style solutions requires that we hardcode change the structure of the World class, something we should be avoiding when modifying how the Entity is supposed to work.

Now, if we use my newinvented OOP, we can actually modify classes outside of their brackets. Then our possibilities are very different. Instead of hardcoding the entity.render loop into the world class, the entity class can actually add this code onto the World class from the outside. Optimizing for situations like "we don't want to render entites behind this bush" now no longer requires that we put so much game logic inside the world class brackets.

Obviously this power can be dangerous. If we later on want to make modifications to these things, we can't find it all under the class World brackets, and it might be hard to grasp how all these additions will work together on a huge project. That's probably why they don't allow it in regular OOP, which is supposed to organize structure.

Now, if anybody raises the objection "Don't reinvent the wheel! Making your own OOP structure on top of OOP is wasteful!" is doing the classic mistake of thinking that OOP was made for games. OOP was not made for gaming or life-to-code 1:1 representations. It was made to bundle and organize methods and properties in a way that would help several people coding together, work better together as a team. If you try to use classes for game objects, or anything like that, it might work but it's not guaranteed.


In fact, I would call you lucky if it just so happens that your programming language is structured perfectly in a way that allows you to place your game content and game rules into it's syntax. But we know that this is not really the case. The truth is that when we are using classes-as-structures we are really limiting our structures into something that classes can hold. That is why we keep running into these problems with inheritance and modularity.

My newinvented OOP-like structure might look like class OOP, but it's not the same anymore than a tool-hammer and warhammer are the same.

example:
http://pastebin.com/1z7X1cK0