Coroutine yield handler

I’m now close to solving the problems with CLS and coroutines - see https://github.com/sequelize/sequelize/issues/6116#issuecomment-232377612

Therefore the time of coroutines is almost upon us! Next question is how to implement.

Method of wrapping ES6 class methods is being covered in https://github.com/sequelize/sequelize/issues/6116.

But also there’s the question of yield handlers.

Bluebird.coroutine() out of the box only supports yielding a Promise i.e. yield promise. But co adds other options like yielding an array of promises for parallel execution (yield [promise, promise, promise] as sugar for yield Promise.all( [promise, promise, promise] )).

I’ve been using co for a long time and find these extra features invaluable. But I think we’d need to stick with Bluebird.coroutine() to maintain CLS support, performance, and nice stack traces. Bluebird.coroutine.addYieldHandler() can then be used to implement some sugar.

There are some projects out there like bluebird-co that do this, but I think it’s important we maintain the principle that Sequelize.Promise is an independent instance of Bluebird and that any yield handler is added only toSequelize.Promise, and not to the global Bluebird instance - as that could cause unexpected behavior in apps/other modules. And I’m not sure if bluebird-co supports that.

Questions:

1. Do others agree with me that the sugar is desirable?
2. Do we agree about the principles I outline above?
3. Any ideas as how to implement the yield handler?

@mickhansen @janmeier @sushantdhiman @felixfbecker

[sushantdhiman]

I did used addYieldHandler(bluebird_co.toPromise); thats why it didn’t rejected, So without any yield handler it did reject. You guys are right 🏁

[overlookmotel]

(with apologies to @sushantdhiman - it seems you’re outvoted on yield handlers, though it’d also be difficult to achieve without adding a dependency, which you’re also against)