That's fair, and I'd agree that mixins and decorators can be more closely related to FP than I initially took them for. I just tend to keep my objects as, basi

That's fair, and I'd agree that mixins and decorators can be more closely related to FP than I initially took them for. I just tend to keep my objects as, basically, structs, and functions bound outside of them, rather than treating them as objects, so questions of composability in such a manner don't come up. Rather than have to write a lot of abstracted out code to support mixins, and then know what assumptions a mixin has about the object choosing to mix it in, there are instead just functions; you want them then reference them, and what they take is spelled out (somewhat more) clearly in the function header, if you can pass in the right arguments, the function can be reused. If you want a set of functions that all work together, then composition, sharing state, etc, falls on you, rather than being implicit in assumptions the mixin and mixing class may make about each other. As you say, a question of taste (especially as to what steps you take to avoid those assumptions). But that said, I've done similar things in merging two objects prior to serializing them out across a REST endpoint. So there it was less a design consideration of composable function containers, and more one of data transformation (not that they're separate beasts; functions as data and all that), but at the same time a lot of the complexities were avoided.