Kata

I've now added code examples. Hopefully they'll help others to figure things out.

On your specific points:

• The original callback will be called after all "added" callbacks have resolved. You effectively are making a queue of callbacks. That original callback will be called once the queue has been emptied, letting you use all the data retrieved, etc. after all the async work has been completed, and triggers triggered.
• Callbacks "added" will be wrapped in a "trigger" function which is then returned. When "triggered", instance.resolve() is automatically called for you.
• Your instance.count explanation is spot on.
• instance.resolve() isn't normally called by the user, though it can be, if they wish. It is, however, automatically called by a trigger, after the relevant callback has been called.
• When instance.count reaches zero as part of an instance.resolve() call, the instance.oncomplete callback is called, and the object wiped.
• instance.count can be changed outside the callbacks, and outside of the control of the CallbackSet itself. Same goes for instance.oncomplete. This is to make the usage of the object as flexible as possible, which is also why instance.resolve can be called manually.

I have made some changes to the description to try to make these things a little clearer. I hope my explanation above has helped you, though?

Okay, it's clearer now. The sample code you added to the description has CallbackSet which should be CreateCallbackSet but other than that it's pretty good.

Do you have any tests that check to see if the callback functions are executed within the correct context?

e.g.

function create(secret) {
  return CreateCallbackSet(function () { console.log(secret); });
}

function add(set, secret) {
  return set.add(function () { console.log(secret); });
}

var set = create('phil');
var t1 = add(set, 'fred');
var t2 = add(set, 'mark');

t2();  // should log 'mark'
t1();  // should log 'fred', then execute oncomplete, which should log 'phil'

If the callback functions aren't run from their original context, secret will be undefined.

Great stuff. And typo fixed--thanks for that.

I think you mean "closure"? And closures are implicitly preserved; there's no way of running a function without it's original closure, as the closure is lumped in with a function when it is created.

You're right. I guess there could be problems if the functions referred to this but I'm not coming up with any easy examples.

The thing is, unless the API supports it (and this one doesn't), there is no way of guaranteeing a callback will have a particular context. So most callbacks just don't use a context, anyway.