Maybe we could also think about implementing different strategies like this: http://reactivex.io/RxJava/javadoc/io/reactivex/BackpressureStrategy.html
but this would have an impact about the current implementation as well because RxGo is only based on channels
and channels would not be able to support those different strategies
You are right. I think that if we would hide channel behind interface it would be feasible to implement them. Currently someone can play directly with channel which implement observable interface
v1 and v2 branch because semver (go module 1.11)
Video content https://youtu.be/aeF3l-zmPsY
9 new PR nice
most of my PR starts from the same branch
but once it is merged, we may have conflicts with the others because obv, they are not sync with upstream..
I need also to integrate what we have in
observer_mock.go in the assertion API (ReactiveX/RxGo#109) and makes something more generic
if they did not follow the Github issue
I'm not a ReactiveX member so I don't known if people are going to listen to me but ok :)
my opinion about the future v2 of RxGo: https://github.com/ReactiveX/RxGo/issues/99#issuecomment-443816758
For the double subscription. In case of v2 second subscription would receive same elements of just sequence as the first?
here we just lose the messages as it is sent in a channel and retrieved during the first subscription
(and there's no way to retry it for the time being)
this function would get emitter as the argument and will be responsible for emitting sequence elements