30 replies to this topic

[Kenneth Gorking]

tobeythorn said:

In non-message passing environments, if I have an array [snake, elephant, bird] and want to call a function move() on each element of the array, I can't without an unnecessary mess, without explicitly casting (which is just a fancy way of calling an explicitly different method for each), which means that I really do have to know about the guts of the objects, and not just their interfaces. Sorry, but to me that is just not encapsulation.

That is just nonsense. The only thing you need, is a shared baseclass with a virtual 'move' function, and nothing more. Your code does not need to know about [snake, elephant, bird], and you certainly don't need any casting.

[tobeythorn]

Quote

That is just nonsense. The only thing you need, is a shared baseclass with a virtual 'move' function, and nothing more. Your code does not need to know about [snake, elephant, bird], and you certainly don't need any casting.

Yes, and then we need to make everything derive from the same base class, even when it doesn't make sense to.

[Reedbeta]

tobeythorn said:

Yes, and then we need to make everything derive from the same base class, even when it doesn't make sense to.

Well, everything that has a move() method can implement an IMove interface (in C++, implemented as an abstract class with no data members), if you want to be able to make move() calls virtually. And an object can implement as many or as few interfaces as necessary.

I admit this would be cumbersome if you needed to have a large number of small interfaces. So maybe from a syntactic perspective, an explicit message-passing language like Smalltalk would be nicer. But the point is, you can certainly do proper encapsulation in C++ if you want.

[tobeythorn]

Reedbeta,
Interesting, I learn something new every day!

[fireside]

Quote

Yes, and then we need to make everything derive from the same base class, even when it doesn't make sense to.

Myself, I consider this a better programming practice because it makes you think about it. There will always be natural divisions in what you are doing. I've done things like entity, moving entity, friend, enemy, etc. and had containers for all of them with some abstracts going back to entity. Java and C# do this by deriving all classes from a base object class. That's really what OO programming is all about as far as I'm concerned. C++ does things that Java doesn't do like multiple inheritance. I don't like it myself. C++ is a full OO language, it's just a little screwy because it was derived from c, not as well organized.

[rouncer]

fireside said:

... Java and C# do this by deriving all classes from a base object class. That's really what OO programming is all about as far as I'm concerned...

Thats what they teach you in your beginning java tutorials, how to extend classes making more than one type of the same class so you can instantiate multiple classes from a single class reference.

I never learnt any more than that, im not a big OO guru, just enough to let me be able to code something largish, which is what c++ (oop) was invented for right? So you could have a largish program and still be able to add to it and maintain it without confusing yourself so much.

[fireside]

Quote

I never learnt any more than that, im not a big OO guru, just enough to let me be able to code something largish, which is what c++ (oop) was invented for right? So you could have a largish program and still be able to add to it and maintain it without confusing yourself so much.

That's what it does for me, anyway. I used to write spaghetti code until I found out about OO. It really kind of forces you to be more organized.

[.oisyn]

Reedbeta said:

I admit this would be cumbersome if you needed to have a large number of small interfaces.

Well I'm with fireside on this. More cumbersome is not always a bad thing. It certainly forces you to think more about your design, which, in the end, makes it simply better. Duck typing and such attracts more cowboy programming.

[rouncer]

yeeha!

[Sol_HSA]

Writing C in "c++ style" is actually rather simple. Basically you need to pass a structure to functions.. like:

VidDataType *v;
v = load_vid("foobar.vid");
init_vid(v);
while (!is_vid_done(v))
{
render_vid(v);
display_vid(v);
}
destroy_vid(v);

SDL & co take it slightly further and include function pointers inside structures. Some oddball platforms even have inheritance of sorts done via some macro trickery, but I wouldn't go that far. I've even seen some stl-like containers done with macro trickery *shiver*.

[jokoon]

Well thanks for the answers !
Seeing the little debate over OOP, I guess that is a good reason carmack didn't choose C++