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

GroupedObservable.mapGroup/flatMapGroup #1668

Closed
benjchristensen opened this issue Sep 5, 2014 · 6 comments
Closed

GroupedObservable.mapGroup/flatMapGroup #1668

benjchristensen opened this issue Sep 5, 2014 · 6 comments
Milestone

Comments

@benjchristensen
Copy link
Member

Explore addition of mapGroup and flatMapGroup to GroupedObservable to allow mapping/flatMapping a GroupedObservable without losing the GroupedObservable type.

This would be a proper solution to the loss of GroupedObservable.from.

/cc @spodila @headinthebox

@benjchristensen benjchristensen added this to the 1.0 milestone Sep 5, 2014
@benjchristensen benjchristensen modified the milestones: 1.x, 1.0 Sep 23, 2014
@benjchristensen
Copy link
Member Author

Moving to 1.x as this is additive and non-essential.

@benjchristensen benjchristensen modified the milestones: 1.x, 1.0.x Oct 7, 2014
@benjchristensen
Copy link
Member Author

The other way we could do this is make Observable methods non-final and then we could change the return types on all of the methods in GroupedObservable ... but need to keep the methods in sync (whenever we add one to Observable we'd need to add the cover method to GroupedObservable to change the return type).

@benjchristensen
Copy link
Member Author

Or we make GroupedObservable not extend from Observable and only have the operators desired for it ... and then toObservable() to get all other operators.

@benjchristensen
Copy link
Member Author

... or we just admit it was wrong to remove GroupedObservable.from and bring that back.

Discussing with @headinthebox the options for solving this (due to Java restrictions) are not pleasant and the single use case where this is needed is probably best solved by keeping GroupedObservable.from.

To summarize:

  1. We make methods in Observable non-final and override all of them in GroupedObservable with a new return type.

Pro: it works.
Con: massive maintenance to keep methods and javadocs synced between the two
Con: allowing overrides of methods on Observable

  1. We make GroupedObservable not extend from Observable and implement all operators in GroupedObservable

Pro: it works while leaving methods final in Observable
Con: massive maintenance to keep methods and javadocs synced between the two
Con: combinatorial operators in Observable must now have overloads for GroupedObservable such as on flatMap and merge otherwise GroupedObservable won't work with them since it's not an Observable any longer

  1. Restore GroupedObservable.from for the use cases where a GroupedObservable needs to be passed around after modifying it into an Observable.

@benjchristensen
Copy link
Member Author

@headinthebox and I feel that despite (c) being ugly, it's the simplest.

@benjchristensen benjchristensen modified the milestones: 1.0, 1.0.x Oct 20, 2014
benjchristensen added a commit to benjchristensen/RxJava that referenced this issue Oct 23, 2014
@benjchristensen
Copy link
Member Author

Added GroupedObservable.from and GroupedObservable.create in #1789

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant