11 ms·

It strikes me that this developer chooses to write an abstraction on top of JS for solving his recurring problems, over simply using language features readily a

It strikes me that this developer chooses to write an abstraction on top of JS for solving his recurring problems, over simply using language features readily available. Promises are as much a pattern or mechanic as callbacks, but the latter feels far more natural in JS. The `promised` decorator is interesting, but it has problems: - The application I work on, and have in mind with this, would need just about every function decorated. - It doesn't account for methods, unless you're default decorating the method, ie.: `Foo.prototype.myMethod = promised(function(/* ... /) { / ... */ });` - Every decorated function takes a noticable performance hit, because things like `Function#apply` and concatenating `arguments` are relatively slow. - It doesn't sit well with me that the example rewrites a method on a prototype declared elsewhere: `console.log = promised(console.log)` Further, the article and library don't even scratch the surface of complicated async flows. Think async versions of common functional-style methods like `map`, `reduce`, etc. For example, a basic scenario from our own build process is: Scan a directory for template files, read them, compile them, then concatenate the result and write it out. We used to have a promise library to do all of this, from handling a build process to performing database queries. I discovered Async.js at some point and haven't look back since: https://github.com/caolan/async https://github.com/caolan/async

MatthewPhillips 14y ago
Promises are likely to be baked into JavaScript at some point in the future[1], so I would recommend becoming familiar with them now. Even if you don't use the pattern personally you will likely run into libraries that do use it once it is part of the spec. I don't too much like the promise pattern this article gives, Q is the definitive implementation: http://documentup.com/kriskowal/q/ http://documentup.com/kriskowal/q/ [1]http://wiki.ecmascript.org/doku.php?id=strawman:concurrency http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
- gozala 14y ago
  Just to be clear this library implements just a subset of Q with exact same API, with only addition of `promised` wrapper. I'm convinced that this wrapper is a better way to deal with promises than dozens of utility functions that you have to learn about. For example Q.all is promised(Array) I find later more intuitive. That's not to say don't use Q! Q is brilliant piece of software and I'd be more than happy to see more people using it.
gozala 14y ago
First of all I implement abstraction using language features and there for I take advantage of it. - I favor maintainability over performance, also keep in mind that promised function take promises as arguments and can't do much until they're fulfilled (associated IO is done) so that small performance hit is insignificant in most of the cases. - You can write your own decorators to wrap constructors and their methods if you need to. That being said, I'd recommend against, mixing mutable state with logic does no good in long run. You'll be better of with functional. - As for map / reduce, promises represent eventual values, not sequences of them. For that there are streams and I have explored that area as well: https://github.com/Gozala/streamer/wiki/stream I have not wrote about it because I don't think it was good idea to dump everything in one post. I'm happy async did that for you.

MatthewPhillips 14y ago

Promises are likely to be baked into JavaScript at some point in the future[1], so I would recommend becoming familiar with them now. Even if you don't use the pattern personally you will likely run into libraries that do use it once it is part of the spec. I don't too much like the promise pattern this article gives, Q is the definitive implementation: http://documentup.com/kriskowal/q/ http://documentup.com/kriskowal/q/ [1]http://wiki.ecmascript.org/doku.php?id=strawman:concurrency http://wiki.ecmascript.org/doku.php?id=strawman:concurrency

gozala 14y ago
Just to be clear this library implements just a subset of Q with exact same API, with only addition of `promised` wrapper. I'm convinced that this wrapper is a better way to deal with promises than dozens of utility functions that you have to learn about. For example Q.all is promised(Array) I find later more intuitive. That's not to say don't use Q! Q is brilliant piece of software and I'd be more than happy to see more people using it.

gozala 14y ago

First of all I implement abstraction using language features and there for I take advantage of it. - I favor maintainability over performance, also keep in mind that promised function take promises as arguments and can't do much until they're fulfilled (associated IO is done) so that small performance hit is insignificant in most of the cases. - You can write your own decorators to wrap constructors and their methods if you need to. That being said, I'd recommend against, mixing mutable state with logic does no good in long run. You'll be better of with functional. - As for map / reduce, promises represent eventual values, not sequences of them. For that there are streams and I have explored that area as well: https://github.com/Gozala/streamer/wiki/stream I have not wrote about it because I don't think it was good idea to dump everything in one post. I'm happy async did that for you.