Break things (followup from #166)

[nordfjord]

This will resolve #167

And remove the functionality deprecated by #166

this means

1. flatMap is no longer available as a module (use flyd.chain instead)
2. Promise swallowing is removed

[coveralls]

Coverage remained the same at 100.0% when pulling f3a899b on nordfjord:remove-promise-swallowing into 082cc86 on paldepind:master.

[coveralls]

Coverage remained the same at 100.0% when pulling a1bc431 on nordfjord:remove-promise-swallowing into 3afb73a on paldepind:master.

[nordfjord]

@paldepind Are you ready to break things?

[StreetStrider]

Time for v0.3.

[c-dante]

Does this mean we can also remove #37?

[paldepind]

@nordfjord I'm ready 😄 I'll take a good look this weekend!

[paldepind]

This looks good to me 🎉

[paldepind]

@StreetStrider

Time for v0.3.

What about releasing this as v1.0.0?

[StreetStrider]

@paldepind If you ask my opinion, I would like we all to investigate end stream related issues, mostly #116 and cast @c-dante @nordfjord, and think about how to signalize errors as well. #35 #164

I also wanted to pull up an deferred emitting discussion, but havent enough «meat» to start that discussion. You see, when you do Promise.resolve(17).then(…) execution is asynchronous (even in example, where result is already in). I think observable libary should follow that behavior for better guarantees for programmer, but flyd is special in that way and very-very synchronous by its nature. This is a topic for another discussion.

Last several months I was developing some build system, where flyd plays the same role that node streams plays in gulp. I'm ok with flyd, but I was forced to solve some very specific tasks, like async stream resolving, promise—stream, stream—promise bridges, value caching/backpessure. Some of them are definitely outside flyd's scope, but due solving them I was thinking that flyd is not ready for v1 yet, and I personally would love some time for changes to occur before things become more stable.