Lazy promises (making done compulsory)

[ForbesLindesay]

Ass suggested by @Raynos in #2 we could make promises lazy until .done is called. Consider the promise(executor) syntax being proposed in promises-aplus/constructor-spec#3

The executor is a function which initiates the asynchronous operation. It has the potential to generate either a resolved promise or a rejected promise. If it's not called, then no rejected promise can exist, so we don't have an issue. So the key idea being presented here is to only call it when we know the promise's rejection will be handled.

By only calling the executor once .done is called, you can guarantee that .done will always be called for all promises. If .done is not called, the entire function will fail to do anything, which will be easy to quickly pick up when developing.

Having done that, it's a simple case of having .done behave as in #5 and crash the application appropriately by throwing the exception in the next turn of the event loop.

Transition

Step 1, ad .done to the promises spec.
Step 2, make sure all promise libraries call .done if present when assimilating promises.
Step 3, wait a month or so for this to be true of most major promise libraries
Step 4, begin using console.warn to warn people that they need to begin calling .done when .done is not called after a period of a few seconds.
Step 5, Implement this feature properly by making the promises lazy.

[briancavalier]

From my comment in #2:

The concept is interesting, indeed. I'm not caught up yet on the Hot and Cold promises thread, but my initial reaction is that lazy promises are something that could easily be built on top of a current Promises/A+ promise. It feels weird to me initially to have this integrated this directly into Promises/A+ promises as they exist today.

[Raynos]

@ForbesLindesay note that this is exactly what gozala/recuders does.

I sometimes fall in to the trap of not calling the reducers equivelant of done but this is a lot less annoying then done not throw the exception. gozala/reducers has a PR for making it's equivelant of done throw which is important enough that I use that branch to develop against because having objects with boxed / hidden errors inside of them is frustrating to no end.

Coming from node callbacks and event emitters I find their error handling correct. Event emitters throw if I don't handle it. callbacks push the error directly in my face every single time.

Reducers has a very similar model to streams, if you start the stream by folding (equivelant of .done) then it will throw any errors it finds so you better handle them

[ForbesLindesay]

@briancavalier Yes, hot and cold promises could be built directly on top of the current promises/A+ spec and would indeed still be valid promises (providing calling .then made the promise execution start). The issue is that doing it that way would not help deal with unhandled rejections. By making hot/cold promises that start when .done is called, we would effectively nullify the whole unhandled rejection problem.