@avelino what about rx-interfaces branch by the way?
Artur Krysiak
@venth
@teivah
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
Teiva Harsanyi
@teivah
@venth this is actually part of the v2 branch
Avelino
@avelino
@teivah rx-interfaces is deprecated now :smile: v2 the future :heartpulse:
Teiva Harsanyi
@teivah
:)
Artur Krysiak
@venth
Yep, and which branch we will develop and make stable. For instance when there will be new operator, shall it be implemented separately for v1 and v2? Wouldn’t be better to have just one branch?
Avelino
@avelino
@teivah You can open issues of upcoming migrations and deployment to version 2, to give visibility of next steps, break N issue, step by step to implement
For the double subscription. In case of v2 second subscription would receive same elements of just sequence as the first?
Teiva Harsanyi
@teivah
well, to be discussed maybe but in RxJava for example if you create an observable from an array, the second subscription is going to receive the same elements as the first one
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)
Artur Krysiak
@venth
If we will create function create that would receive function as argument then we could overcome the channel issue
this function would get emitter as the argument and will be responsible for emitting sequence elements
Teiva Harsanyi
@teivah
you mean as an end-user or as a maintainer of RxGo?
Artur Krysiak
@venth
Either. Such a function ease implementation of plenty of operators
Like empty - just emit complete
Teiva Harsanyi
@teivah
yes agreed
Artur Krysiak
@venth
error emit error
abd so forth
Teiva Harsanyi
@teivah
but I'm just pointing out that the current behavior is not similar to what we have in the other Rx implementations