-
Notifications
You must be signed in to change notification settings - Fork 226
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
Bring back static factories again, this time with autocomplete! #88
Conversation
CC @uber/mobile-platform-android |
Seems a little nicer. I like starting everything with To be fair:
Definitely isn't worse than before. Do you feel strongly enough to make a breaking change? |
True, but that's even wordier. My main argument against True on generics, but less is more :) We're not at 1.0 yet, so it's ok. I'd deprecate scopers in 0.3.0 and provide some structural replace templates in the changelog, then remove for 1.0. |
|
||
public final class AutoDispose { | ||
|
||
public interface ScopeHandler { |
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.
Would love to see some javadocs for these public, consumer-focused methods.
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.
Definitely. Just wanted to get feedback on the API first before doing a doc and tests pass
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.
Seeeeeeems like people are ok with this, so going to go through and update the docs and tests to use this new API. One change I'm going to poll to some contacts and possibly make - instead of saying |
Notes for structural replace. If using Java 8, replace FlowableJava 8 /
|
Because it's a util class
aa081cd
to
5b6d69a
Compare
Tests and docs updated now, along with a rebase. Seeking opinions on the final namings but this is review-ready from an implementation standpoint @tyvsmith @jbarr21 @AttwellBrian |
This is yet another attempt at static factories, but I feel pretty good about this.
Prior art: #61 #17 #42 #43
Basically - the static API wasn't possible before because of java generics issues. I could never find a sweet spot of conciseness/readability and tooling support (basically - IDE autocomplete). After playing with this more though, I think I've found the sweet spot.
The IDE will happily autocomplete generics IFF there are no parameters. I don't know why, but yeah that's how it is. Doesn't matter if the parameters are generic themselves either, just presence alone. This kind of works ok though, as we can leverage this as a plus to separate scope capture separately to make a single point of entry, then fan out to types.
The gist of how this works is that there's a single
AutoDispose
class with three public static overloads ofwith()
, each taking one of the supported scope types. These return an implementation of aScopeHandler
, which is just an interface that has 5 methods (one for each rxjava type, akaobservable()
,single()
, etc). Because these methods don't have parameters and the generics are still on the method signature, the IDE autocompletes! This feels a little more readable too, similar to Picasso's API. One extra key stroke, but more obvious to read than "ObservableScoper" IMO.It's effectively a sort of rehash of #5, but only scope and type since we can leverage the
to()
operator now.If this looks good from an API perspective here, I'll update the PR with tests/docs and deprecate the scoper API (with the intention of removing/making it not public it by 1.0). This should be pretty easy to migrate via structural replace as well
Now code looks like this:
And an added bonus - generic isn't necessary in Java 8!