-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed AbstractProducer to replace AbstractOnSubscribe #2813
Conversation
*/ | ||
@Experimental | ||
@SuppressWarnings({ "unchecked", "rawtypes" }) | ||
public static <T, S> Observable<T> create(Action1<ProducerState<T, S>> onRequest) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this conflict with Groovy and Clojure because of type erasure? I'm concerned that 2 overloads that take functions will collide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quite possible. Any suggestions for a name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about it ... probably need to play with the code a little more to get a feel for it.
I really like the AbstractOnSubscribe helper for making backpressure-aware Observables, but I've avoided writing a RxScala wrapper for it since it still seems to be in a bit of a flux. Will this refactoring, or something like it, be merged soon or am I better off writing a RxScala wrapper for the existing AbstractOnSubscribe in the short term? |
This is not a refactoring but a potential replacement to it to allow exploiting a case of batched requesting and infinite requests and reduce the infrastructure overhead of |
FWIW, I went ahead and made a RxScala wrapper for this. Didn't run into any issues other than the inevitable generics compiler errors (managed to crash scalac without much issue), which are now handled. Looking forward to this getting merged so I can use it my Scala code. |
Related to #3003 Trying to figure out async batching ... |
Waiting on proposal from @stealthcode (in #3003) to compare options. |
PR #3118 has much lower overhead and apart from slight API concerns it is a better replacement for |
Proposed replacement for
AbstractProducer
which gives access to the requested amount allowing batch or fast-path value emission.I've skipped the detailed javadoc until the feedback about using this instead of
AbstractOnSubscribe
.