Re: Existence Based Polymorphism

On 3 June 2010 12:05, Stuart Golodetz <[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.

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.

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

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