[hintingonwhoiam]

The point is not a lack of objects but a lack of OOP. Yes, there are "objects" but there is also a separation between objects and methods etc..

The issue with m->set_volume(.08) is it becomes difficult to tell what happens inside set_volume() because in the method scope you have access to the internals of the "m" object, not just the interface.

With mixer_set_volume(m, .08) you have ".08" and "m" but only the interface "m" exposes anywhere else. Thus it becomes easier to reason about effects.

[nlawalker]

Can you expand on this? I'm not sure I follow, but maybe there's something particular to C++ here that I don't get as I'm not well-versed in it.

>> The issue with m->set_volume(.08) is it becomes difficult to tell what happens inside set_volume()

Isn't that the point? That you shouldn't have to care what happens inside set_volume? If mixer was designed and implemented well, then set_volume (along with the rest of its interface methods) should consistently and correctly handle its internal state.

[hintingonwhoiam]

Whether you are dealing with OOP, functional, or some other pattern it is always the point to create abstractions which you and others can forget about how they work.

Thus m->set_volume(.08) and set_volume(m, .08) should not require you to understand what happens internally as the user of either.

More generally in programming that is the point.

My only point is that of scope and essentially search space -- set_volume(m, .08) can only access the public interface of "m". While, m->set_volume(.08) could do almost anything to m. In a perfect world, with perfect programmers thinking the same way about what "set_volume" means or should do the separation of state and action would be less valuable.

This not to say OOP is > Functional or vice-versa. I think there is a place for both but that is a MUCH larger and more nuanced conversation :)