var withThis = (object, f) => function bound() {
return f.apply(object, arguments);
}
function getCredentialsByToken(token) {
return newCredentials(token)
.then(withThis(User, User.findByName));
} var withThis = (object, f) => function bound() {
return f.apply(object, arguments);
}
function getCredentialsByToken(token) {
return newCredentials(token)
.then(withThis(User, User.findByName));
}When you're writing in functional style, you'd use arrows, which work nicely both for small lambdas and for writing combinators that can be partially applied. When you're writing in a more procedural style, generators are your "do syntax" equivalent(-ish):
async(function* getCredentialsByToken(token) {
credentials = yield NewCredentials(token)
return User.findByName(credentials.userName)
});
The difference between "functional" and "procedural" style here is nothing more than monadic bind operator vs do-notation, but what you have above or in the initial response is nothing like that.
Also I'm not sure "arrows" -- http://www.haskell.org/haskellwiki/Arrow -- means what you think it means in the context of functional programming? It's not sugar for `function(){}`...
As for style, using combinators is usually considered to be specific to functional programming, right?
IMO the interesting part is how the terse arrow function syntax in ES6 puts combinators on the same level of expressiveness as everything else. Contrast to ES5 you have to use the awkward `return function() {}` syntax, and you have to do something similar in go - `return func (param type) type { ... }`
Both styles are now almost equally terse and you can pick either depending whether you feel its more appropriate in the given situation.
This isn't a terseness issue; it's an error issue. Favoring yield/return and equivalents over sequential code in CSP is exactly the same as favoring goto over while, or goto over exceptions. Necessary sometimes? Yes. Something to be celebrated and preferred? No.
The trouble is, of course, that in Javascript runtimes the "yield" or equivalent is how scheduling is achieved, because there is no capacity for preemption.
Thus, Node.js returns us to the bad old days of Windows 3.1 and System 6, where one faulty bit of code grinds the entire system to a halt.
Edit: Go goroutines of course also have a cooperative scheduler currently, but at least the result of having it isn't baked into the idioms and language constructs.
Still, scheduling would continue to be cooperative via yield (just split amongst multiple threads). Go is clearly much further ahead in that regard :D
[1]: https://groups.google.com/forum/#!topic/golang-nuts/hZjvk-EP...
note: I'm curious, doesn't shared state from those closures let you shoot yourself in the foot in Go? You still have to be careful not to use anything not thread-safe that can potentially change...