2 ms·

This is probably a somewhat fringe sentiment, but reading this reminds me very much of http://codeofrob.com/entries/you-have-ruined-javascript.html http://codeo

This is probably a somewhat fringe sentiment, but reading this reminds me very much of http://codeofrob.com/entries/you-have-ruined-javascript.html http://codeofrob.com/entries/you-have-ruined-javascript.html (I was making very similar comments while reading this) I'll readily admit I'm biased against OOP; I much prefer functional approaches. When I write Javascript, it tends to be pretty functional, with minimal OOP conventions. But that said...all the problems this addresses are self-inflicted problems. The very start of the article even says as much, "Mixins solve a very common problem in class-centric OOP" - that is, "these problems are only problems because you want to write Javascript in class-centric OOP", something it wasn't really designed for (and the constant attempts have led to Ecmascript 7 and the 'class' keyword, which I find myself shaking my head at; again, see prior link, at trying to make Javascript feel 'enterprisey'). Find another way to go about it maybe? The subclassFactory example he gives...if I saw that in a code base I'd want to punch someone. Because without the writeup he gives, I'd be staring at it, and the functions it calls, for a good 20 minutes before figuring out what it's doing. And all it's doing is trying to shoehorn a specific paradigm into a language not written for it. I mean, you can do it, sure, but -why-? I don't really like Javascript but at least I feel pretty productive in it; why would I make it harder on myself, and everyone who reads my code after me, by trying to make it something it isn't?

braythwayt 11y ago
Perhaps the author ought to spend some time reading a book like JavaScript Allongé and learn how Functional Programming in JavaScript is done ;-) https://leanpub.com/javascriptallongesix/read https://leanpub.com/javascriptallongesix/read
- lostcolony 11y ago
  Sarcasm aside, I know raganwald (you?) can approach things functionally. :P My comment isn't to imply he can't (nor that I'm particularly good at it), nor to imply anything about his choices when writing code (as I said, he correctly notes that this is an issue when trying to write class-centric OOP in Javascript; this says nothing about his views on whether class-centric OOP in Javascript is a good idea or not). And, certainly, come ES6, mixins get some language help with Object.assign. My point is simply that if in ES5 you have to fight this much with the language to try and shoehorn it into a particular paradigm, maybe you've picked the wrong paradigm for that language. And the fact so many people try, and so many authors have written ways to try and shoehorn that paradigm into the language (as it stands at ES5), tells me that it -really- is probably not the best choice. And the insistence in doing so seems like a misplaced "make it behave like Java" that brought to mind that URL I linked. That's not to say thinking about it isn't itself a worthwhile endeavor. That's not to say that seeing that it can be done in Javascript isn't a point in Javascript's favor. That's not to say there isn't a demand by people for the language to behave this way, and that others understandably try to meet that demand. But it is to say that it's solving a problem that is self-inflicted, by dint of choosing to use classical inheritance in a language that was designed to support prototypal inheritance.
  - braythwayt 11y ago
    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.

braythwayt 11y ago

Perhaps the author ought to spend some time reading a book like JavaScript Allongé and learn how Functional Programming in JavaScript is done ;-) https://leanpub.com/javascriptallongesix/read https://leanpub.com/javascriptallongesix/read

lostcolony 11y ago
Sarcasm aside, I know raganwald (you?) can approach things functionally. :P My comment isn't to imply he can't (nor that I'm particularly good at it), nor to imply anything about his choices when writing code (as I said, he correctly notes that this is an issue when trying to write class-centric OOP in Javascript; this says nothing about his views on whether class-centric OOP in Javascript is a good idea or not). And, certainly, come ES6, mixins get some language help with Object.assign. My point is simply that if in ES5 you have to fight this much with the language to try and shoehorn it into a particular paradigm, maybe you've picked the wrong paradigm for that language. And the fact so many people try, and so many authors have written ways to try and shoehorn that paradigm into the language (as it stands at ES5), tells me that it -really- is probably not the best choice. And the insistence in doing so seems like a misplaced "make it behave like Java" that brought to mind that URL I linked. That's not to say thinking about it isn't itself a worthwhile endeavor. That's not to say that seeing that it can be done in Javascript isn't a point in Javascript's favor. That's not to say there isn't a demand by people for the language to behave this way, and that others understandably try to meet that demand. But it is to say that it's solving a problem that is self-inflicted, by dint of choosing to use classical inheritance in a language that was designed to support prototypal inheritance.
- braythwayt 11y ago
  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.