[rlidwka]

> Without inheritance, as soon as you want to cast mixer to something else, you're either relying on binary wizardry by the compiler

Why would you want to cast mixer to something else? What real-life task does it solve?

> If we assume we have both a hardware mixer and a soft mixer which both have the set volume method, we wan't polymorphism so we can treat them equally.

Polymorphism isn't OOP feature. You can have overloaded `mixer_set(struct, int)` without any OOP wizardry involved.

[scomment]

> Why would you want to cast mixer to something else?

Did you ever heard about interfaces? You can have a IMixer interface, a Mixer baseclass and some concrete mixer classes depending on your task. Like null-mixer for mocking, software mixer for legacy computers, hardware mixer with GPU support, etc. Use your imagination, Luke!

[chipsy]

Or you could just have data. The behavior of mixing is not going to change because of those things.

[Retric]

Let's suppose you want labels, text boxes, and buttons on a form.

Now you can do this without OOP or making a huge chunk of form code, but OOP is a natural fit. Especially if we may want to add pictures or video in the future.

[seivan]

Are you saying all these outlets (labels, text box, buttons) are inheriting from a base FormObject that can be rendered?

That would work without OOP. Make a FormRender component that manages that logic (being rendered in a form) and other components, one that manages a keyboard, other that can be clicked and handle hover, touch states, etc.

[Retric]

Sure, but routing get's complex in your solution. The point was OOP is a natural fit for collections of different types in some context ex:GUI, Simulation, etc. The classic OOP case is probably a MUD where OO code ends up being very straightforward.

IMO, the problem is it works really well in so many contexts that people end up trying to use it everywhere.

[Jtsummers]

OO in MUDs seemed so natural to me, I think, because they're closer to the actor model that OO was really designed for. Instead of "methods", many objects in MUDs (depending on the system, I used to know more when I was research writing a MUD engine in erlang), respond to messages in more of a smalltalk-style.

[seivan]

Routing? I'm just saying that OOP is as much of a perfect fit to GUI that Entity Component Systems (composition) are.

[Retric]

ECS works well when you can predefine everything ahead of time. But, it must be extended for every additional type.

As to messaging, consider what happens when you add JavaScript that can change the DOM. Now, you need to pass messages in both directions not just What is your Height- Width, but also my Height-Width has changed. Animated Gifs or Videos now want to update things in real time, and other windows can cover parts of your view port.

And let's not forget about transparency.

PS: ECS can still work, but it starts getting really complex.

[scomment]

And you started slow reinvention of OOP!

[seivan]

No, the name of the game is composition. See ECS in game dev.