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

Discussion Episode 8: Damn Functional Programming with Paco Estevez #57

Open
sockeqwe opened this Issue Mar 2, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@sockeqwe
Copy link
Collaborator

sockeqwe commented Mar 2, 2017

No description provided.

@sockeqwe sockeqwe added the discussion label Mar 2, 2017

@sockeqwe sockeqwe added this to the Episode 8 milestone Mar 2, 2017

@artem-zinnatullin

This comment has been minimized.

Copy link
Owner

artem-zinnatullin commented Mar 2, 2017

@pakoito

This comment has been minimized.

Copy link

pakoito commented Mar 2, 2017

Errata: in 30:30 I say that to do filter + map to change based on type you need flatMap. There's actually an operator for that called ofType.

@artem-zinnatullin

This comment has been minimized.

Copy link
Owner

artem-zinnatullin commented Mar 6, 2017

Yup (we have custom ofType() which is filter + map under the hood, that what I was talking about), btw, @pakoito pls just write separate comments instead of editing one because nooooone receives emails about edited comments 😸

@artem-zinnatullin

This comment has been minimized.

Copy link
Owner

artem-zinnatullin commented Mar 7, 2017

Btw, here is the code of problematic ofType (not filter as I said in the podcast, my bad):

// This can be applied to any observable no matter which type is emitted by upstream 
// and may lead to no events in downstream if incompatible types are used.
inline fun <reified Downstream : Any> Observable<*>.ofType()
: Observable<Downstream> = ofType(Downstream::class.java)

// This version has type bounds, but for some reason Kotlin compiler requires 
// you to also pass upstream type, though I think it should be able to infer it.
inline fun <Upstream, reified Downstream : Upstream> Observable<Upstream>.ofType2()
: Observable<Downstream> = filter { it is Downstream }.map { it as Downstream }

Same problem of ofType1() will occur if you'll use stardard RxJava's ofType(Class) in both 1.x and 2.x.

@artem-zinnatullin

This comment has been minimized.

Copy link
Owner

artem-zinnatullin commented Mar 7, 2017

Examples:

Observable.just(1).ofType(String::class.java).subscribe { /* Compiles :( */ }

Observable.just(1).ofType1<String>().subscribe { /* Compiles :( */ }

Observable.just(1).ofType2<Int, String>().subscribe { /* Not compiles! But requires specifying upstream type */ }
@sebaslogen

This comment has been minimized.

Copy link

sebaslogen commented Mar 18, 2017

Fantastic program, I quite enjoyed it 👍
My suggestion would have been to split it into two shorter parts (there was a good separation of topics about half way through the program), it took me a while to find the free time to listen to the whole episode.

Thanks for explaining Monads, the concept is still exploding in my mind but your explanation is close to what I found in this monads ELI5 and the concept is starting to crystalize in my mind.

I really liked the part where you guys discuss the similarities between Mosby3 and Paco's solution, although I would like a deeper dive in the differences of each solution to understand the nuances. Super interesting topic 👌

Note: The testing robots thing is indeed an abstraction from the UI layer for testing and it's originally called PageObject pattern coming from the old wild web world. Martin Fowler introduced it here: https://martinfowler.com/bliki/PageObject.html

Keep up with the high quality of the topics! 💯

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