Lukas Eder

Just a matter of style. I've realised that suddenly, most implementation has moved to the interface, rather than the backing class and that feels kind of weird for a "default"...

@stephenh Hmm, just encountered another issue, proving my concerns to be justified: I've implemented `Collectable` (#166), a common super type for `Seq` and the new `Window`. Both `Seq` and `Window`...

> Thanks to them, one can clearly see what's the main part of the interface, and what's just an extension to it. This is crucial if you want to implement...

> This, however, does not mean that all the implementations must be in Seq That's what this issue is about :) > because the methods in Seq can simply delegate...

Indeed, we could simply add the method to `Async` and adapt the arguments for use with the remaining API. For simplicity, I supported the version accepting a `Supplier` only, but...

... for the record, unlike in jOOQ where all asynchronous `Runnable` and `Supplier` lambdas are blocking (as they contain SQL code), I think in this case we shouldn't automatically use...

Hmm, what would that `blocking()` thing return?

... having said so, I'm not sure if I find that "blocking" concept strong enough to justify the additional argument to the method

> I'd like to fix this issue by creating a constructer for tuple2 so that users can choose whether to swap bounds by themselves. Thanks for your suggestion. For the...

Have you benchmarked this implementation via JMH? I wouldn't be surprised if the synchronisation + hashmap access is slower than the current implementation!