Skip to content
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

Merged
merged 5 commits into from
Sep 5, 2013
Merged

Conversation

benjchristensen
Copy link
Member

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

@benjchristensen
Copy link
Member Author

@bcotton Great pull request, I like how you also worked on buffer.

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) {
Copy link
Member Author

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>?

Copy link
Contributor

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.

@cloudbees-pull-request-builder

RxJava-pull-requests #239 SUCCESS
This pull request looks good

@@ -15,6 +15,6 @@
*/
package rx.util;

public interface BufferClosing {
public interface Closing {
Copy link
Member Author

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?

Copy link
Contributor

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.

@benjchristensen
Copy link
Member Author

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.

@benjchristensen
Copy link
Member Author

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).

@jmhofer
Copy link
Contributor

jmhofer commented Sep 5, 2013

I know that I'm being kind of a pain in the butt here, but there's also the question whether the various Chunk and Window classes are co-/contra- or invariant in their type parameters...

I'll go examine the code more closely now...

@jmhofer
Copy link
Contributor

jmhofer commented Sep 5, 2013

I made the wi(n)dow maker typesafe. - There are also some more raw types in ChunkedOperation, though.

jmhofer added 2 commits September 5, 2013 19:25
…/extends fluff; also simplified api by removing a few useless super definitions (there's no super of Opening and Closing)
@jmhofer
Copy link
Contributor

jmhofer commented Sep 5, 2013

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 window-merge branch?

@benjchristensen
Copy link
Member Author

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).

@cloudbees-pull-request-builder

RxJava-pull-requests #240 SUCCESS
This pull request looks good

@benjchristensen
Copy link
Member Author

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.

@bcotton
Copy link

bcotton commented Sep 5, 2013

Go ahead. No need for glory :-) Happy to help

@benjchristensen
Copy link
Member Author

Thanks @bcotton ... I'll merge now and release 0.12 fairly soon.

benjchristensen added a commit that referenced this pull request Sep 5, 2013
@benjchristensen benjchristensen merged commit 2221198 into ReactiveX:master Sep 5, 2013
@samuelgruetter
Copy link
Contributor

I'm confused. These methods all are instance methods, but they do not depend in any way on this, so they could be made static. However, the better way would probably be to remove the argument called source and replace all occurences of source by this.
Am I missing something?

@benjchristensen
Copy link
Member Author

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.

@jmhofer
Copy link
Contributor

jmhofer commented Sep 6, 2013

Oops, embarrassing. :-) Completely missed this, too.

@benjchristensen
Copy link
Member Author

Just release 0.12.1 ... making its way through Sonatype now.

rickbw pushed a commit to rickbw/RxJava that referenced this pull request Jan 9, 2014
rickbw pushed a commit to rickbw/RxJava that referenced this pull request Jan 9, 2014
billyy pushed a commit to billyy/RxJava that referenced this pull request Jan 13, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants