Re: Existence Based Polymorphism

Richard Fabian wrote:
> On 3 June 2010 12:05, Stuart Golodetz <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     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?)
>
>  
> I can't begin to hope to change what language I develop in, as there's 
> not sensible alternative for games development, so it's definitely a 
> change in thinking or paradigm rather than language. When I say 
> "coding in C" I mean using global functions, data stores and other old 
> school solutions. When I say "coding in C++" I mean using object 
> oriented approach, using virtuals, class inheritance, templated 
> containers etc. I'm not even sure a change in language would help 
> anyway, as C++ already has all the tools necessary to do what I want 
> to do.
Ok - if you're arguing for people to use other paradigms beside OO in 
C++ then I agree with you. I think there's certainly a tendency for 
people to overuse OO. I also think that C++ doesn't make separating 
interface from implementation as easy as it should (we could do with 
some sort of module system, which unfortunately didn't make it into the 
new standard).

There's a slight irony to using "coding in C++" to mean OO whilst 
arguing for people to think about using different paradigms in C++, by 
the way :)
> Also, there's almost no way to change everything at once, so one of 
> the criteria for doing this work was that it had to, in some way, be 
> able to be rolled out "one module at a time".
>
>>     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 :)
>
>
> I saw it and didn't know if it was a joke or not... just because C is 
> a subset of C++ doesn't mean you get to use it. You can't add methods 
> to a class behind the scenes in C++, which would have allowed for a 
> better data hiding opportunity.
If you're forced to write C++ in an object-oriented style, that's not 
down to the language itself. Nothing technical is preventing you from 
writing procedural code in C++.
> One of the biggest problems I have with OO C++ right now is that to do 
> it well, you have to use too many tricks. I want a programming 
> paradigm where there are no tricks, but you still have all the benefits.
>
> If you're doing OO in C++, you can't hide your implementation as 
> easily as you still have to provide classes for your users, at which 
> point you're talking to them through your implementation.
>
> I'm not too bothered about encapsulation from a data hiding point of 
> view any more, but there's still the issue of changes to 
> implementation affecting a lot more than just the code that provided 
> an interface. In C style development, if the implementation changes, 
> the user need never know anything about it at all. They were never 
> privy to the implementation details at any point, and never assumed 
> they would. Many old APIs were built like this. Does anyone need to 
> worry about anything when the OS changes the way FILE* is implemented?
I hope I'm not oversimplifying your point, but are you essentially 
criticising the need to put a class's private members in the header file 
you supply to users (assuming you don't use the pimpl idiom)? If so, 
then I agree that it's annoying. That's more a C++ problem than an OO 
problem though.
> I realise this is becoming a bit far off topic now, so I'll just close 
> with this:
>
> OO C++ Objects do represent something, but normally, they only 
> represent one thing. Data oriented approaches appreciate that data can 
> be taken to have different consequences or meanings just by looking at 
> it from different angles. If you lock yourself down to classes of 
> data, you have to invent new classes or transforms or both to 
> represent all the non-standard* ways of looking at that same data 
> which adds layers of indirection to your code, and possibly your 
> thinking. If you never invent a class for the data, you merely have to 
> invent a view into it to begin to use it in the appropriate way. OO 
> C++ just seems to get in the way of simple transforms like this.
>
> * where standard invariably == whoever drew up the class first
It sounds like what you want is a model-view design pattern - which you 
can do fine in C++. I guess I'm missing something obvious though?

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