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

Bike-shedding: switchMapFirst and switchMap #915

Closed
benlesh opened this issue Dec 7, 2015 · 11 comments
Closed

Bike-shedding: switchMapFirst and switchMap #915

benlesh opened this issue Dec 7, 2015 · 11 comments
Milestone

Comments

@benlesh
Copy link
Member

benlesh commented Dec 7, 2015

At the very least, we need to change switchMapFirst to switchFirstMap to match our naming scheme.

But switchFirst doesn't really seem to name what it's doing.

Basically it takes the first Observable it gets and merges it, dropping all subsequent Observables it gets until the first one is complete, then it takes another one.

Ideas I've had so far:

  1. tailDrop or dropTail - https://en.wikipedia.org/wiki/Tail_drop
  2. pick - because it picks the first and drops the rest until the first is done.
  3. chooseFirst - same as pick, really, but it chooses the first and drops the rest.
@benlesh
Copy link
Member Author

benlesh commented Dec 7, 2015

My initial thought is pick. I don't like choose right off, because it sounds like there should be some sort of predicate to decide whether or not to merge the incoming observable. Also, pick is pretty terse.

The downside is I'm not sure pick describes anything much better than switchFirst, but at least it doesn't have the confusion of having "switch" in there.

@benlesh
Copy link
Member Author

benlesh commented Dec 7, 2015

NOTE: I'd like to get decisions on this very quickly, as I don't want to break the API after beta release, if we can avoid it.

@jeffbcross
Copy link
Contributor

My gut says chooseFirst.

@jayphelps
Copy link
Member

exhaust or drain.

@benlesh
Copy link
Member Author

benlesh commented Dec 8, 2015

it's so focused on whatever observable it has that it ignores all incoming observables until that one observable completes. Then it drops it like it never existed at all and focuses on the very next observable it sees. It's obsessed with whatever observable it gets, so much so that the world around it fades away. Even if the observable it has never emits a value, it'll sit there, staring at it... waiting... watching... But if that observable it gets blasts data at it, it takes it all. It's greedy and patient. It's focused. It doesn't care about just the "first" observable it gets... it cares that it has one, any one, to call it's own, until the observable's death do they part... then it moves on, it wants another.

@jayphelps
Copy link
Member

scumbagObservable()

@benlesh
Copy link
Member Author

benlesh commented Dec 8, 2015

At the very least, we need to change switchMapFirst to switchFirstMap to match our naming scheme.

This minimum thing has been done with #921

@staltz
Copy link
Member

staltz commented Dec 8, 2015

I liked exhaust that @jayphelps suggested. Another option is stick as in "stick with this fella until he ends". Other options: loyal, steadfast, stay.

I don't like pick alone because it has the same problem as choose: both sound like they expect a predicate. To get the "picks the first and drops the rest until the first is done" connotation you'd need an additional word, like pickFirst. Same problem as chooseFirst.

@trxcllnt
Copy link
Member

trxcllnt commented Dec 8, 2015

@staltz: I liked exhaust that @jayphelps suggested. Another option is stick as in "stick with this fella until he ends". Other options: loyal, steadfast, stay.

brungYa as in, "dance with the one that brung ya."

@benlesh
Copy link
Member Author

benlesh commented Dec 8, 2015

LOL

@benlesh benlesh closed this as completed in 9b565c9 Dec 9, 2015
@lock
Copy link

lock bot commented Jun 7, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants