Re: Existence Based Polymorphism

Richard Fabian wrote:
> 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?
This doesn't actually follow - only a small proportion of Effective C++ 
is about object-oriented programming, and even if the entire book were 
about OOP, it wouldn't necessarily suggest that OOP was bad. It might 
suggest that the author thought that there was a lot to say about how to 
do OOP well (which is true). Effective C++ exists primarily because C++ 
is hard to do well, not because OOP is bad, or even hard to do well. C++ 
is not just about OOP.
> 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.
I thought a reason why people find it easier to get stuff done in 
business software was that they're using languages that worry more about 
productivity than performance. Personally I find I'm dramatically 
quicker writing code in languages that don't force me to type certain 
bits out twice (in both header and source file) and then wait for a 
lengthy rebuild. That's nothing to do with OOP though - I'm generally 
doing OOP when I code in those other languages too.

Your other point's a bit hard to address, because it's not clear whether 
you're primarily in favour of a different language, or a different 
paradigm. You seem to be saying that encapsulation and polymorphism can 
be done simpler and better in languages other than e.g. C++. If so, 
that's true - but I was under the impression that the reason people used 
C++ for games wasn't due to the elegance of its support for 
encapsulation and polymorphism in any case. (It's more to do with 
performance and control, surely?)
> 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.
See Tom Plunket's reply :)

FWIW, I think there are certainly a lot of things that could be done in 
a nicer way in C++ - we could really do with decent module support, for 
a start. I also don't think that the way C++ does OOP is especially 
wonderful. None of this means that OOP itself is necessarily bad 
(although neither is it the one true way).

Cheers,
Stu
> 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

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