[skylan_q]

While looking through the slides, I was wondering:

Is there some community-standard way of naming/declaring a JS function to let the programmer know just by reading the function's name that it will return a promise instead of a final computed value? I'm interested in knowing how people handle this. It's easy to forget that a function doesn't return a promise if the function name makes no mention of it, so I just make it explicit in the function name... but that's just how I handle it.

[vec]

I'm getting in the habit of letting the caller decide, something like the following:

    myAsyncFunc = function (param1, param2, callback) {
      var usingPromises = (callback === undefined);
      var returnVal = usingPromises ? Q.defer() : this;

      someFunction(function (err, res) {
        if (usingPromises) {
          err ? returnVal.reject(err) : returnVal.resolve(res);
        } else {
          callback(err, res);
        }
      });

      return returnVal;
    };

So if I call myAsyncFunc(foo, bar) it returns a promise and if I call myAsyncFunc(foo, bar, cb) it returns itself for chaining.

[tantalor]

Functions should be documented with the types of their parameters and return value.

[skylan_q]

I suppose I've just learned to really appreciate the "?" and "!" at the end of ruby function names...

[joshguthrie]

If that function is "supposed" to be async and its last argument is not something looking like "callback", there's a great chance it's a Promise.

Otherwise, there's no "naming scheme" for promise-based functions.