-
Notifications
You must be signed in to change notification settings - Fork 62
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
Better name for... #48
Comments
The purpose of this combinator is not clear for me. Could you show/add to the docs an example of its usage? |
In the iOS application I'm working on, I'm using that combinator in various places to basically limit the frequency of updates. Here is a simplified snippet from one such case: Stream.merge viewChanged (Stream.indefinitely (timeOutMillis 30000))
|> Stream.hold (timeOutMillis 2000)
|> ... Basically, |
So, it produces events not more frequently that each 2 seconds, and the latest event is always yielded. Is [sample()](http://reactivex.io/RxJava/javadoc/rx/Observable.html#sample%28long, java.util.concurrent.TimeUnit%29) from Rx do the same? BTW, it would be great to have such diagrams visually describing how each combinator works. |
Or maybe [throttleLast()](http://reactivex.io/RxJava/javadoc/rx/Observable.html#throttleLast%28long, java.util.concurrent.TimeUnit%29) is closer to I'm struggling to see the difference between the two though. |
Thanks! I was going to say that |
OK, maybe one of these debounce combinators would fit? :) |
Yes, [this one](http://reactivex.io/RxJava/javadoc/rx/Observable.html#debounce%28long, java.util.concurrent.TimeUnit%29) seems to fit well. And its nicely named. |
That debounce actually seems to be identical to Heh... I must say that I find it interesting that Erik Meijer @headinthebox rants about pull semantics in https://www.youtube.com/watch?v=pOl4E8x3fmw#t=37m48s . Yes, semantics are important, but I have yet to see the semantics of Rx operators specified precisely anywhere. It is clear that the push model breaks if your callbacks don't return in time, so I don't think that the push model can magically make your program "reactive" rather than just "responsive". If you have enough CPU time to handle all events in time, then you can have essentially the same timing properties with the pull model when your consumers eagerly pull all the streams. On the other hand, the pull model directly supports a kind of back pressure in that streams can be lazy. But, getting back to naming, I think that I might rename |
Looks good. And the pics are very helpful. |
I think it may be a good idea to contrast |
Does someone have an idea for a better name for the hold combinator? See the doc here.
The text was updated successfully, but these errors were encountered: