for example:

var cache = thunkify(fs.readFile)('filename');

cache(function (err, res) {
  // this works
});
cache(function (err, res) {
  // this doesn't
});

You want consistent results every time you await the same object.

Hope to add some comments, i can't really understand

Hi tj,I 'm new to nodejs.I don't know the function named done where transfer.I have been very confused

Because it doesn't call setImmediate before calling the callback function it is possible to unleash zalgo. e.g.

var delay = thunkify(function (time, callback) {
  setTimeout(callback, time);
});

var result = delay(100);
setTimeout(function () {
  console.log('a');
  result(function () {
    console.log('c');
  });
  console.log('b');
}, 500);

Expected:

a
b
c

Actual:

a
c
b

TypeError: this.on is not a function

Hello, is it possible to incorporate the LICENSE file inside the repo and the npm package ? Now it's missing. It's implied by MIT license that if licensed under the MIT the source code must be accompanied by full license text. If the license file is not in the npm package or in github repo a lot of people cannot use it (technically none).

Thank you

When we use the mysql:

var query = thunkify(pool.query)
exports.data = function(req, res) {

    co(function*() {
        var result = yield query('select mid, name, mtype, p.....');
        var data = [];
       .....

it's always wrong with undefined property, we find that because the context of query function changed, and we change the thunkify function:

function thunkify(fn,context){
  assert('function' == typeof fn, 'function required');

  return function(){
    var args = new Array(arguments.length);
    var ctx = context||this;

    for(var i = 0; i < args.length; ++i) {
      args[i] = arguments[i];
    }
    return function(done){
      var called;

      args.push(function(){
        if (called) return;
        called = true;
        done.apply(null, arguments);
      });

      try {
        fn.apply(ctx, args);
      } catch (err) {
        done(err);
      }
    }
  }
};

so that we can use it like this:

var query = thunkify(pool.query, pool)

after all, we now can use thunkify with not-global function.

any way you could tag the current state?

Hi,
Can I use

var args = Array.from(arguments);

to replace

var args = new Array(arguments.length);
for(var i = 0; i < args.length; ++i) {
      args[i] = arguments[i];
    }

@visionmedia there is a code snippet in thunk module:

return function(){
    var args = new Array(arguments.length);
    var ctx = this;

    for(var i = 0; i < args.length; ++i) {
      args[i] = arguments[i];
    }
    ...
}

I'm just curious about why not just use the code below which is simpler?Is there some problem with it?

var args = [].slice.call(arguments);

the thing is, thunkify is pretty cool when used together with core.async in clojurescript

example:

(ns express-test.core
  (:require-macros [cljs.core.async.macros :refer [go]])
  (:require [cljs.nodejs :as node]
            [cljs.core.async :refer [put! <! chan]]))

(defn async [thunk]
  (let [c (chan)]
    (thunk (fn [err res] (put! c res)))
    c))

(defn -main []
  (let [express (node/require "express")
        fs      (node/require "co-fs")
        app     (express)]
    (doto app
      (.get "/" (fn [req res]
                  (go
                    (let [c (async (.readdir fs "."))]
                      (.send res (<! c))))))
      (.listen 3000))))

(set! *main-cli-fn* -main)

unfortunately right now i'm forced to wrap the thunk in order to return a chan (which is then used in the go block). It would be waaay cooler if thunkify could return clojurescript channels directly (maybe through a configuration parameter or something, to be transparent to existing co-wrappers.
it appears to me that the easiest way here is to rewrite thunkify in clojurescript and to (optionally) return a chan from there, but i'm open to suggestions :)

-yawnt

It seems the example in the README changes the readFile function from the standard library in such a way that other modules will no longer be able to use the readFile functions like they are used to. Is this correct or have I misunderstood something?

It seems to be that it can lead to problems that could be avoided by simple storing the thunkified readFile to a separate variable and not back onto the fs object. I realise that "this", if use inside the readFile function, would not work like this which leads to my second suggestion.

It would also be nice if the README described the difference between thunkify and function.bind since they seem very similar. All test-cases work with using bind even if it makes the code slightly awkward looking. Is this the main thing that thunkify aims to fix?

Now that the license has been added via #30 would you be able to publish a new version? I know this is a pain for an old repo, but its still technically a legal issue in some cases if a transitive dep is missing a license.

Thanks again, and sorry for the trouble