Because the camera was using velocity and acceleration and was collidable, I derived it from our PhysicalObject class, which had those characteristics. It also had another characteristic: PhysicalObjects could take damage. The air strikes did enough damage in a large enough radius that they were quite literally "killing" the camera.
Um, no? If their camera wasn't a PhysicalObject, they'd have had to write custom code for handling the camera case for anything that handles PhysicalObjects. All this means is that perhaps a PhysicalObject shouldn't be the thing that takes damage.
The reason is that inheritance is too coarse-grained and promotes bundling together lots of unrelated concepts. So it's likely that with a finer grained system, they would have separated physics and damage in different classes. They might have still made the mistake of not separating them, or of copy-pasting the damage object into the camera anyway, so the point and punchline of the story still stands.
They might have still made the mistake of not separating them, or of copy-pasting the damage object into the camera anyway, so the point and punchline of the story still stands.
The possibility that a programmer could make a mistake in the implementation of a paradigm is not an argument against that paradigm. The first part of your comment is very real and very valid, but copy-pasting is a potential issue regardless of your programming language.
I am convinced that this is not just a programmer's mistake. This is an illustration of the problem with the paradigm itself. Inheritance makes you want to glue unrelated things together.
Inheritance views the world as fundamentally hierarchical; you can divide things up into branches of a tree. A node on the tree either has all of a set of functions or none of them. Any code you put into Reptile will never be needed by a Mammal, and will never be inappropriate for an object that needs other things in Reptile.
But of course, that's unrealistic. Where would you put swim()? Where would you put fly()? Code reuse can't always be decomposed into a tree. And in an inheritance paradigm, you get ugly workarounds in that case -- cut and pasted code, nasty multiple inheritance hacks, or util classes. All bad things.
What you want are things coupled, not by convenient proximity in current function, but by logical relationship. You want a class that has swimming-related code and nothing else, that any swimmer can use without preconceptions about whether it's a Reptile or a Mammal. You want, in short, Traits.
Inheritance is not a design methodology, it’s a tool. As a tool it does not “view the world”, unless it’s meant in the sense that when you only have a hammer, every problem looks like a nail to you. When you only have inheritance in your toolbox, things are going to end badly indeed. But that does not mean that inheritance is a bad tool.
Actually I want multiple inheritance. That way I can write that a crocodile is a reptile and a swimmer or that camera is a game object and it is collidable but not damageable.
Yes it can make your code more complex, but you can also use it to make the game more clean.
I think you should be very careful about using this kind of argument. This is the mindset of a cult. Why didn't X work? well you just didn't use enough X! . I have kind of a visceral reaction of disgust when this is used, because it encourages the retention of silly ideas without really using reason, logic or evidence to defend them.
It's only the mindset of a cult when the theory in question is not demonstrated to work or is not predicated on reason. Suppose I wrote a catapult simulator to test the validity of designs for a competition, and then my simulator ignored physical attributes such as wind speed, material strength, elevation, and weight. The physics being used have been known by the modern world for centuries, but I haven't applied enough of that theory to create a valid simulator.
I do not make any similar claim about the validity of object-oriented programming, but I find your argument as a reaction to my comment rather silly. People make mistakes in paradigms all the time. Read The Daily WTF is you want to observe how badly people can mangle code. I'm not suggesting that all your problems with OOP can be solved by using more OOP, just as I'm not saying that the chance hat a programmer will misunderstand for-loops in Lisp means that we should throw out functional programming.
Your physics example is not a good analogy, because your critique of the simulation is not that the hypothetical didn't use enough physics, but instead you point out a number of very specific physical attributes that were missing, and you would have been able to explain the effect each of those attributes would have on the simulation. This is evidence and reason based argument. This is NOT like the argument you used for object oriented programming.
I don't know why you think I'm defending OOP. I'm not. My original point was that copy-pasting is not an argument against any programming paradigms. The possibility of programmer error is not a valid argument against using a programming language, just as a person being unskilled at spelling is not a valid reason to criticize English, Mandarin, French, etc.
That's why you use delegation and traits instead of inheritance. sometimes the alternative to a bad idea isn't the even stupider thing you did before you found out about it.
FYI, the game was 'Force 21', "a Real-time Strategy game made by Red Storm Entertainment in 1999 that features a storyline which has US forces fighting PRC (Chinese) forces in the year 2015."
"You view the game mainly from the Tactical 3D window. The camera is, sadly, always situated just above the lead vehicle in the selected platoon. A free roaming camera would have been better as it would have given you more opportunities to view the action. Still, the camera is very useful and really succeeds at drawing you into the action. The camera is very, very easy to use--just bump the edges of your screen with the mouse...well, the mouse cursor, not the actual mouse itself. The camera then spins around the lead unit of the platoon. Vertical movement isn't as good. The angle of the camera doesn't allow you to look straight down on your units or get down on the ground beside them. Oh well, c'est la guerre. There's also a Strategic view that's better for getting an overall impression of the terrain elevation, but it's no good for seeing the action. For the overall impression of the battle, I preferred to use the tiny strategic window in the corner of the screen."
This is what's wrong with inheritance.