-
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
Window Operator #349
Window Operator #349
Conversation
…Java - updated to use new OnSubscribeFunc - updated to use super/extends generics
@bcotton Great pull request, I like how you also worked on Now that I've merged this with master I'll add some inline comments on the code with questions. If another pull request is needed so you can take back control of the branch, go right ahead and just cherry pick these 2 commits on to a new branch of your own. |
* An {@link Observable} which produces connected non-overlapping windows containing at most | ||
* "count" produced values. | ||
*/ | ||
public Observable<Observable<T>> window(Observable<T> source, int count) { |
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.
Now that we're doing covariant super/extend generics, do we need to look at any of these Observable<T>
and change them to Observable<? super T>
?
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.
This takes an Observable<T>
, instead it would have take an Observable<? extends T>
to ensure covariance of Observable
. Normally, the return type shouldn't be affected.
RxJava-pull-requests #239 SUCCESS |
@@ -15,6 +15,6 @@ | |||
*/ | |||
package rx.util; | |||
|
|||
public interface BufferClosing { | |||
public interface Closing { |
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.
I am still not a fan of these random classes/interfaces sitting in rx.util
, but I can't think of anything better to do with them.
I don't really want them in rx
and they don't seem to warrant their own package, but they seem different than util
.
We could put them in Observable
as inner classes but that may be a bad precedent if there are more of these cases down the road.
Does anyone else have a better idea of what to do with them?
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.
I don't mind much about them staying in rx.util
for the timing being. I definitely wouldn't want them directly in rx
, and Observable
is already a monster. If somebody comes up with a great name for a package to put them into, I'm all for moving them, but otherwise, I'd leave them as is.
This looks like a great addition of code, and not a trival one, so thank you @bcotton! I do not have the time to review it for thread-safety but nothing jumps out as obviously wrong. The unit tests appear to cover the use cases well and based on them the behavior looks correct. I have not done a comparison with Rx.Net to determine if we have covered all cases. If anyone else could do that I'd appreciate it. Once we've got resolutions to the (1) generics and (2) Func0 questions I posted above, this appears good to merge unless anyone else can find issues. |
If possible I'd like to get the above items resolved today so I can merge this and release 0.12 by end of today (US time). |
I know that I'm being kind of a pain in the butt here, but there's also the question whether the various I'll go examine the code more closely now... |
I made the wi(n)dow maker typesafe. - There are also some more raw types in |
…/extends fluff; also simplified api by removing a few useless super definitions (there's no super of Opening and Closing)
Now I think I'm done with the important things. The chunks look invariant to me at first sight. I tried to get everything typesafe that wasn't already, and again added a lot of wildcards... - it's all here @benjchristensen Should I put up a pull request against your |
I just pulled them off your branch to this pull request. Looks like both of my questions/concerns are now addressed. Any last thoughts on placement of util classes? Otherwise this looks ready to merge (if the build passes). |
RxJava-pull-requests #240 SUCCESS |
Thanks for the reviews @jmhofer. @bcotton It looks like this pull request only has you as the author but not commiter due to the crazy merge I had to do. If you want to take these commits and reapply them so you get the credit, please do so. I'll wait a few hours if you can do it, otherwise I'll proceed with this pull request. |
Go ahead. No need for glory :-) Happy to help |
Thanks @bcotton ... I'll merge now and release 0.12 fairly soon. |
I'm confused. These methods all are instance methods, but they do not depend in any way on |
No you're not missing anything ... we all did who reviewed this! So funny ... an earlier review had the methods change from static to instance, but apparently only the static keyword got removed. I'll go submit a fix and release 0.12.1 ... too funny (and embarrassing) we all missed this. Thanks for reporting it. |
Oops, embarrassing. :-) Completely missed this, too. |
Just release 0.12.1 ... making its way through Sonatype now. |
Window Operator
Manual merge of #337
Since this pull request was submitted there were significant changes to the
create
operator and generics, so I manually merged into master. I have not actually reviewed for behavior, but unit tests are passing and code structure looked good.This is for issue #102