Announcing Do
Tim Caswell
Marak Squires
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Michael Stillwell
Interesting! I made a sort of adapter for the Array.prototype.*
functions to allow them to be used with Do.chain:
Function.prototype.chainable = function() {
var t = this, a = arguments;
return function(self) {
return function(callback) {
callback(t.apply(self, a));
}
}
};
This makes it possible to do
Do.chain(
Array.prototype.filter.chainable(function(x) { return x > 3
})([1, 2, 3, 4, 5]),
Array.prototype.map.chainable(function(x) { return x + 2 })
)(function(x) {
sys.debug(sys.inspect(x));
});
which returns
[6, 7]
I called this "chainable", but would "continuable" be a better name?
I was thinking a continuable higher-order function would be more like
Function.prototype.continuable = function() {
var t = this, a = arguments;
return function(callback) {
callback(t.apply(t, a));
}
}
which can then be applied to functions that otherwise return a value such as
function add(i, j) {
return i + j;
}
like so
add.continuable(3, 4)(function (x) { console.log(x); });
// -> 7
Michael
Max
earlier post (http://groups.google.com/group/nodejs/browse_thread/
thread/70aa5b78f3ba0133/9bd78a8cb1305ccc) seem not just possible,
but...almost trivial. (i.e. I have n slow-running tasks I want to run
in parallel sorta thing, without n tcp servers or something).
Looking forward to trying it out.
Max
Mark Hansen
Check this out, people!
aHeckman
stuff. Keep it coming.
On Feb 16, 11:41 pm, Tim Caswell <t...@creationix.com> wrote:
> At the request of a couple of the guys off IRC, I packaged and documented my Do library that I've been blogging about in the Control Flow series onhttp://howtonode.org/
Felix Geisendörfer
A few questions:
* Do you allow multiple values to be passed to the callbacks?
* If so, how do you aggregate them in Do.parallel?
* How do you distinguish between error/success state in Do.parallel?
I'm pretty convinced at this point that continuable's are a good idea,
but I think single argument and single callback are the two design
choices that will make them simpler to use than promises. Everything
else is just the current promises API in disguise.
--fg
Tim Caswell
On Feb 18, 2010, at 3:37 AM, Felix Geisendörfer wrote:
> Interesting library.
>
> A few questions:
>
> * Do you allow multiple values to be passed to the callbacks?
I've been flip-flopping on this one. I think the latest version of Parallel only passes the first argument from each continuables output.
> * If so, how do you aggregate them in Do.parallel?
Parallel itself takes multiple argument or a single array as input. If you give it an array, it outputs all the results as a single argument in an array. If you pass in multiple arguments, then it outputs multiple arguments to the callback.
> * How do you distinguish between error/success state in Do.parallel?
If any of the parallel items has an error, then the output is that error. the success is only fired after all the inputs come back as success
>
> I'm pretty convinced at this point that continuable's are a good idea,
> but I think single argument and single callback are the two design
> choices that will make them simpler to use than promises. Everything
> else is just the current promises API in disguise.
>
I'm open to some suggestions. on the finer points of the helper api. I've got to do some client work for the next bit.
> --fg
>
> On Feb 18, 5:51 am, aHeckman <aaron.heckm...@gmail.com> wrote:
>> Thanks Tim. Started using Do.parallel after reading your post. Good
>> stuff. Keep it coming.
>>
>> On Feb 16, 11:41 pm, Tim Caswell <t...@creationix.com> wrote:
>>
>>
>>
>>> At the request of a couple of the guys off IRC, I packaged and documented my Do library that I've been blogging about in the Control Flow series onhttp://howtonode.org/
>>
>>> Basically it's a utility belt for managing higher-level abstractions on my modified version of continuables.
>>
>>> http://github.com/creationix/do
>
Tim Caswell
Kris Zyp
On Feb 18, 2:37 am, Felix Geisendörfer <fe...@debuggable.com> wrote:
> Interesting library.
>
> A few questions:
>
> * Do you allow multiple values to be passed to the callbacks?
> * If so, how do you aggregate them in Do.parallel?
> * How do you distinguish between error/success state in Do.parallel?
>
> I'm pretty convinced at this point that continuable's are a good idea,
> but I think single argument and single callback are the two design
> choices that will make them simpler to use than promises. Everything
> else is just the current promises API in disguise.
What happens if you attach multiple listeners to a continuable? It
appears that this could cause the original function to fire multiple
times, which obviously could be hazardous if it has non-idempotent
side-effects. The core idea of promises is to allow for various
consumers to (safely) utilize a value that may be fulfilled in the
future. The process.Promise provides this functionality, but
continuables do not appear to provide this safety, and it seems it
would be a huge stretch to call them promises (unless any object that
represents an asynchronous action can be called a promise, but that is
a pretty watered down definition).
And just my personal preference, I don't find "(" to be more readable
way of providing async callback than ".addCallback(". Fewer keystrokes
doesn't seem to necessarily make more readable code, IMO.
Kris
Tim Caswell
It's not just about fewer keystrokes, it's simpler too and doesn't depend on an external library to use (continuables that is). My Do library just makes them easier to use, but it's not required to use continuables.
Kris Zyp
On Feb 18, 9:09 am, Tim Caswell <t...@creationix.com> wrote:
> You can't attach multiple callbacks to a continuable. Just a single callback and a single errback. I think these are much simpler than promises, but fulfill 90% of the use cases for promises.
>
> It's not just about fewer keystrokes, it's simpler too and doesn't depend on an external library to use (continuables that is). My Do library just makes them easier to use, but it's not required to use continuables.
It is indeed simpler to implement, but simpler to implement != simpler
to use, and having to worry about hazards for the 10% use cases seems
like a significant extra mental load for developer. The composable
nature of promises and direct analogy to synchronous values creates a
flexible and easy to *use* model.
Anyway, I don't want to be critical of your work, it is interesting
stuff. However, would you be able use your library simply with
functions that take callbacks, rather than functions that return
functions that take callbacks? It seems like that would be even
simpler than continuables and the side-effects would be more explicit.
Kris
inimino
> It is indeed simpler to implement, but simpler to implement != simpler
> to use, and having to worry about hazards for the 10% use cases seems
> like a significant extra mental load for developer. The composable
> nature of promises and direct analogy to synchronous values creates a
> flexible and easy to *use* model.
Continuables are composable...
> Anyway, I don't want to be critical of your work, it is interesting
> stuff. However, would you be able use your library simply with
> functions that take callbacks, rather than functions that return
> functions that take callbacks?
...and it's because they return functions that take functions.
This is why you can write utility functions that take, say, an array
of continuables, and asynchronously give you an array of results.
Tim Caswell
errrrr , this seems awesome?
Ryan Dahl
> Wrote a howtonode.org article about it, enjoy!
> http://howtonode.org/do-it-fast
Thanks Tim - this makes things very clear.
howtonode is a really nice project.