Re: Existence Based Polymorphism

----- "Richard Fabian" <[email protected]> a écrit :
> On 28 May 2010 17:01, JS Zirani < [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?

Not to derail your argument, but this is more a problem of "C++ is bad" than "OOP is bad". Although I love C++, I have to admit that the 1998 and 2003 versions of the language have just too many quirks to consider when you want to write serious code. The direct consequence is that the resulting code is often quite hard to read. The 2011 version is supposed to be simpler and to be defined in a better way in order to avoid many of the problems that required the publication of these books. 

And of course, procedural development typically don't have such books, because procedural languages are often far simpler than C++. In procedural languages, a symbol refers to a unique entity. In C++ this is no more the case (due to polymorphism and to other features such as namespace support (a symbol can have different definition depending on the namespace in whitch it is declared)). The same is true for assembly programming : I've never saw a book about assembly programming traps and pitfalls, but on the other hand I do think that requiring a whole project to be done using assembly programming is a bad idea :)

> 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. 

This is again a limitation of the language you use (C++, C#, Java and many many other), not a requirement of OOP. If one can use a language where : 

* declaration is separated from implementation (as in C, C++ or Object Pascal (Delphi))
* declaration of private members is implicit

Then you still have an OO language but you can efficiently hide implementation details without sacrificing to performance.

As a side note, I would say that using a proxy class to hide implementation details only can be as efficient as not using the proxy class (when done correctly, either the proxy class function calls or the client class function calls are automagically inlined by the compiler). You loose a bit of performance if you use the full pImpl idiom (meaning that your proxy class is a polymorphic class ; each call is then a virtual function call). 

> 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.

This sentence is a bit unclear to me (but I'm French ; so my English is not as good as I would like it to be). If you could explain it, that would probably help me to see the interest of the technique. 

> 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.

You're not crazy and this is not pointless - you just described what a language shall support to enable multiple dispatch and to support multimethods (this is not the case for C++, but more advanced OO langages such as Nice (which is based upon the JVM) allow them). In multiple dispatch (which is a type of ad hoc polymorphism), all arguments to the function are equal, including the implicit argument "this", and type deduction is done at run-time instead of compile time. Thus, if you have a hierarchy of colliding object classes, the call to obj1.collide(obj2) will exhibit different behavior at run time, depending on the __dynamic__ type of obj1 __and__ obj2. In C++ and other languages without multi-dispatch, only the dynamic type of obj1 have an effect on the code that is executed. This is similar to your FSM, where moving from one state to another depends on the current state and on the action - and not just on the current state.

> 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.

The virtual call cost is highly overrated. Sure, it shall not be used in a high performance loop - but with recent compilers, it often translates to a memory lookup (get address of a function depending on the value of this) + a jump + the regular function call. I would be surprised if your code is as efficient as this in release mode. As always, code, measure, decide :)

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

Best regards,

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