3 ms·

Yes. Humans tend to everyday-think in terms of agents with identity. Take that mentality over to programming and you will end up with coupling and state, typica

Yes. Humans tend to everyday-think in terms of agents with identity. Take that mentality over to programming and you will end up with coupling and state, typical OOP spaghetti. Of course, good OOProgrammers don't do this. I remember reading C++ intro books in my early teens. Class Train prints choo choo. Class Car says honk honk. Both inherit Vehicle. I thought, why do they do this dumb shit and how is it related to programming?

merlincorey 7y ago
> I remember reading C++ intro books in my early teens. Class Train prints choo choo. Class Car says honk honk. Both inherit Vehicle. I thought, why do they do this dumb shit and how is it related to programming? As someone who was once a known C++ and OOP zealot that later found their way to functional programming and now sits middle of the road on things, I am curious how exactly you would go about implementing polymorphism in C++ for, say a video game, where different entities had different sounds such that a single function can play the sounds of many entities without using this "train is a vehicle" and "car is a vehicle" text-book inheritance? I'm not saying I cannot think of other ways to do it, but I am not really sure what the deficiency in your example actually is -- that seems like a pretty straightforward use of inheritance, and I can see it being useful in say a game as I made an example of.
- vnorilo 7y ago
  Sure; inheritance is a relatively efficient way to implement single dispatch polymorphism in C++. Not much more to it. Thinking about it in that way has made my life easier. Not that there's anything wrong as such in the example, it is just somehow all the examples were so inane.
- Jtsummers 7y ago
  In that case, does it need to be a property of the class to play the "Toot toot" wav file instead of the "Honk honk" wav file? Or is that a property of the object. Distinct classes make sense when they have distinct behaviors, in this case they have the same behavior (play a sound) but with a different effect (tooting or honking). Make it a parameter to the class constructor. Would you make distinct classes based on the amount of damage creatures could inflict on the PC? Or would you make a parameterized class that allows the amount of damage to be changed?
  - merlincorey 7y ago
    I was thinking definitely of more complicated sounds than simply playing a static wave form stored in a file. I absolutely agree if that was the case, it's very simple to parameterize it. In a more complicated situation, where perhaps you want some sounds to be simple wave forms and some sounds to be more complex sequences of wave forms mixed in some manner, then I was envisioning a `SoundEffect` base class from which simple and complex sounds could be derived, providing a single-dispatch polymorphism. A `SoundEffect` instance (or more likely mapping of names to sound effects) would certainly be a property of whatever entity contained it... but the `CarHornSoundEffect` is a `SoundEffect` and `TrainHornSoundEffect` is a `SoundEffect` relationship remains a straightforward and effective use of inheritance to provide single-dispatch polymorphism.

merlincorey 7y ago

> I remember reading C++ intro books in my early teens. Class Train prints choo choo. Class Car says honk honk. Both inherit Vehicle. I thought, why do they do this dumb shit and how is it related to programming? As someone who was once a known C++ and OOP zealot that later found their way to functional programming and now sits middle of the road on things, I am curious how exactly you would go about implementing polymorphism in C++ for, say a video game, where different entities had different sounds such that a single function can play the sounds of many entities without using this "train is a vehicle" and "car is a vehicle" text-book inheritance? I'm not saying I cannot think of other ways to do it, but I am not really sure what the deficiency in your example actually is -- that seems like a pretty straightforward use of inheritance, and I can see it being useful in say a game as I made an example of.

vnorilo 7y ago
Sure; inheritance is a relatively efficient way to implement single dispatch polymorphism in C++. Not much more to it. Thinking about it in that way has made my life easier. Not that there's anything wrong as such in the example, it is just somehow all the examples were so inane.
Jtsummers 7y ago
In that case, does it need to be a property of the class to play the "Toot toot" wav file instead of the "Honk honk" wav file? Or is that a property of the object. Distinct classes make sense when they have distinct behaviors, in this case they have the same behavior (play a sound) but with a different effect (tooting or honking). Make it a parameter to the class constructor. Would you make distinct classes based on the amount of damage creatures could inflict on the PC? Or would you make a parameterized class that allows the amount of damage to be changed?
- merlincorey 7y ago
  I was thinking definitely of more complicated sounds than simply playing a static wave form stored in a file. I absolutely agree if that was the case, it's very simple to parameterize it. In a more complicated situation, where perhaps you want some sounds to be simple wave forms and some sounds to be more complex sequences of wave forms mixed in some manner, then I was envisioning a `SoundEffect` base class from which simple and complex sounds could be derived, providing a single-dispatch polymorphism. A `SoundEffect` instance (or more likely mapping of names to sound effects) would certainly be a property of whatever entity contained it... but the `CarHornSoundEffect` is a `SoundEffect` and `TrainHornSoundEffect` is a `SoundEffect` relationship remains a straightforward and effective use of inheritance to provide single-dispatch polymorphism.