3 ms·

It’s a question of taste. To me, hierarchies of classes are not very JavaScript, but mixins written as decorators are very JavaScript. To me, overriding funct

It’s a question of taste. To me, hierarchies of classes are not very JavaScript, but mixins written as decorators are very JavaScript. To me, overriding functions and calling `super` is not very JavaScript, but writing function combinators like `before` and `after` is very JavaScript. To me, JavaScript is about composing bunches of single-responsibility things, not writing big things. So to my taste, mixins and decorators are in a deep way, strongly related to functional programming, while the sugar for stuff like classes and special syntax for getters and setters is not.

lostcolony 11y ago
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.

lostcolony 11y ago

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.