-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Remove ScalarObservable optimizations for map, filter, reduce, scan, etc? #1142
Comments
AGAIN: I don't care if we keep them or remove themThe idea was that we'd implement them and try them out during beta. |
I'm in favor of this in general, but this specific |
We should make them lazy. If someone wants to optimize so their ScalarObservable chains are only invoked once, they can multicast with a ReplaySubject. |
This all sounds good... I'll let this simmer overnight. I think we should also try to add some "protips" or something to the docs that say things like "If you're creating chains like |
I'm also rather neutral on this one, but I tend to agree with Paul. |
Meh. Let's remove them for now. Individuals that want this behavior could always monkey-patch ScalarObservable I suppose. |
Just before this is done in response to my issue can I double check that the problem I had is actually what's been discussed? I have a feeling it might just be a bug (see my latest comment on the issue).... FWIW I do agree though, just not in my name! 😄 |
There are two issues: 1. the optimization which were discussing removing here, and 2. an apparent bug in the optimization that needs to be fixed or removed with the optimization. |
- remove usage of ScalarObservable for optimization - implementation of ScalarObservable still remain for possible further usage closes ReactiveX#1142, ReactiveX#1150, ReactiveX#1140
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
There is an issue #1140 that just popped up (I was waiting for it).
I'm neither hot nor cold on these optimizations. So let's discuss them:
The Good:
Observable.of(a)
, but notObservable.of(1,2,3)
. They only effect ScalarObservables.Observable.of(a).map(toSomethingElse)
very often. It's code that only really shows up in demos and playground code normally, and/or it's an anti-pattern usually.The Bad:
The text was updated successfully, but these errors were encountered: