Re: Existence Based Polymorphism

> There is an impedance mismatch between the idiomatic OO models people have been taught to build and the requirements for dealing with largely homogeneous groups of data in a high performance way.

Exactly. Nothing about OOP says that you have to combine code and data. It's just a convenient thing to teach.

MSN
________________________________
From: [email protected] [[email protected]] On Behalf Of Conor Stokes [[email protected]]
Sent: Wednesday, June 02, 2010 4:47 AM
To: [email protected]
Subject: Re: [Sweng-Gamedev] Existence Based Polymorphism

C++ handles encapsulation just fine, because encapsulation is about hiding access to implementation details from outside code, not from programmer or compiler eyes. In fact, in C++ you can do encapsulation you can't in C, which is hide the values of a data-type when passing by value.

This hiding thing from compiler eyes problem is fairly specific to C++ (not OOP) and it's creaky single pass every-source-file-lives-alone compilation method, not the OOP encapsulation mechanism at all. That's the reason you get pImpls, to stop having to include every header under the sun and sometimes to avoid giving out code if you are say, selling a library. Other statically typed OOP languages like C# and Java don't have these problems because they have modern compilation systems and well defined ABIs. In C#/.NET you also have the internal protection modifier, which means you don't need to use inheritance from interfaces/virtual base classes to hide even otherwise external implementation details.

Decision tables suffer from two big flaws that virtual functions don't; the expression problem (you can add a new class that implements a virtual function without modifying any other code or data) and a lack of type safety (although, this could be removed with first class support). To do the equivalent to what virtual functions do (execute different logic based on the incoming data), decision tables have overhead; usually a similar overhead to a virtual function (because they're usually a table of function pointers), although they might have better cache locality for the table lookup (not if you have a big table obviously), they're not going to gain you much in terms of the code cache. They are both tools with certain roles and they both have a place in a large codebase that does many different things.

There is an impedance mismatch between the idiomatic OO models people have been taught to build and the requirements for dealing with largely homogeneous groups of data in a high performance way. The reason the idiomatic OO is more applicable in the larger programming ("business") world is that it was designed to suit that world. A lot of the NoSQL movement is about people moving away from the relational normalized form you're advocating to things like graph databases because normalized form is extremely horrible for representing cyclic heterogeneous graph structures in a scalable way. Luckily, games currently don't have to deal with many large cyclic heterogeneous graphs.

However, we shouldn't throw the baby away with the bathwater here, what we need is a better way to model proper re-entrant encapsulated components (what OO gives us) in combination with dealing with large amounts of homogeneous data. I think there are some excellent component systems that have been presented recently that strike that balance very well (mixing OO and data oriented principles) and even ideas like model-view-controller (a very OO idea) on top.

Cheers,
Conor

________________________________
From: Richard Fabian <[email protected]>
To: [email protected]
Sent: Wed, 2 June, 2010 6:03:19 PM
Subject: [Sweng-Gamedev] Existence Based Polymorphism

On 28 May 2010 17:01, JS Zirani <[email protected]<mailto:[email protected]>> wrote:
It is a bit out of topic, but I think you should say "OOP has
pitfalls" instead of "OOP is bad". "OOP is bad" is really the wrong
message.



I've been thinking about this a lot over the last few months, and come to think that if OOP was not "bad", then there wouldn't be so many "effective C++" or "C++ gotchas" like books out there. How many "pitfalls of procedural development" books have you seen?

Although OOP does have abstraction nailed, which might be why we're seeing a lot more coders getting stuff done in business software, some things that OOP proclaims to do well, specifically encapsulation and polymorphism, can be done simpler and better in games development languages we don't associate with OOP.

Encapsulation is better handled by C. This can be seen in how you cannot actually hide all the implementation details in C++ without using techniques such as pImpl or virtual base classes. Each of which actually impacts performance in some way.

On the polymorphism side, I stumbled across a slight issue in C++ that goes away completely if you use sparse components to provide existence based processing to provide state information.
Polymorphism comes in many flavours. If you think of C++ style runtime-polymorphism as being the ability for the program to be unaware at link time to know how the object will react, try to think of dynamic-runtime-polymorphism as being the ability for the program to be unaware _between calls_ to know how the object will react.
If you think this is pointless and crazy, may I remind you that you've probably used Finite State Machines before.
I've already touched on this with replacing bools and enums with table entries, but the lovely thing about this is that you get stronger polymorphism than C++ virtuals, without the virtual call cost.

--
fabs();
Just because the world is full of people that think just like you, doesn't mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com