RxJava 2.0 Planning?

[thomasnield]

Is it worth discussing how this API will change with RxJava 2.0? With the release candidate out it's probably not a bad time to think about Flowables and all that.

https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0

Should we create a new branch for the 2.0 development?

[MarioAriasC]

Yes, we need to start working on that.

What about supporting 1.*?

[lenguyenthanh]

IMO, we should keep supporting both 1.x and 2.x. We can versioning follow rxJava convention.

[thomasnield]

I agree. We probably should support both 1.0 and 2.0 as long as 1.0 is supported. That could be a long time I imagine.

[aldoborrero]

Yeah, having covered both versions could be very helpful indeed. As @thomasnield said I'll gladly contribute.

[sorinirimies]

@ all so is there a plan to support rxJava 2.0? Thx.

[thomasnield]

RxJava2 is now released, so this probably should become a priority at some point. I'm a bit overloaded with other initiatives right now otherwise I'd contribute. Personally, I have to have RxJava-JDBC ported over to RxJava2 before I even consider migrating. And then I have to migrate RxJavaFX and RxKotlinFX. There's quite a bit of work for the Rx community.

[JakeWharton]

Let's use the major version to solve three problems with this library:

• It's never had a stable release
• It has no defined scope so it's historically been a random slew of unrelated things.
• It lacks internal consistency of what it does include.

Right now I have a hard time seeing how someone could recommend its use vs. just copying out what you like/need.

On Sat, Oct 29, 2016, 12:59 PM Thomas Nield notifications@github.com wrote:

RxJava2 is now released, so this probably should become a priority at some point. I'm a bit overloaded with other initiatives right now otherwise I'd contribute. Personally, I have to have RxJava-JDBC https://github.com/davidmoten/rxjava-jdbc ported over to RxJava2 before I even consider migrating. And then I have to migrate RxJavaFX https://github.com/ReactiveX/RxJavaFX and RxKotlinFX https://github.com/thomasnield/RxKotlinFX. There's quite a bit of work for the Rx community to do.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ReactiveX/RxKotlin/issues/80#issuecomment-257102843, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEERD4BZE1FShCqEslVFNSfeb4mtxgks5q43t_gaJpZM4JtuBX .

[thomasnield]

Btw, I guess we have a problem with nullable types and RxJava 2.0. I think you have to use a Guava/Java 8 Optional

class NullableCarrier<T>(val value: T?)
fun <T> T?.carry() = NullableCarrier(this)

[thomasnield]

@JakeWharton I can live with minimizing the amount of functionality in this library.

[ScottPierce]

So I don't see any movement in this library pushing towards RxJava 2.0. Is anyone driving this?

[MarioAriasC]

@ScottPierce currently we're working in a leadership transition, once is finished, works on 2.0 will be published (AFAIU there is already some advances)

[thomasnield]

After a stable 1.0 release, the main priority of 2.0 should be coming up with an Optional type, and creating nullable type interop and Observable<Optional<T>> extension functions for operators.

[JakeWharton]

I find it hard to justify an entire optional type in this library. The platform type seems appropriate, and if you don't have Java 8 then you're on your own.

On Tue, Jan 3, 2017 at 7:58 PM Thomas Nield notifications@github.com wrote:

After a stable 1.0 release, the main priority of 2.0 should be coming up with an Optional type, and creating nullable type interop and Observable<Optional> extension functions for operators.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/ReactiveX/RxKotlin/issues/80#issuecomment-270269029, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEXByQTAFeDfRtIVJ7jPgDtfXH7i_ks5rOu7QgaJpZM4JtuBX .

[thomasnield]

But the platform type won't emit if it is null, correct? I guess it makes sense that endeavor would be something the user would implement on their side, with Java 8, Guava, or whatever else.

[JakeWharton]

Sorry I meant Java 8's Optional when i said "platform type"!

On Tue, Jan 3, 2017 at 8:13 PM Thomas Nield notifications@github.com wrote:

But the platform type won't emit if it is null, correct? I guess it makes sense that endeavor would something the user would implement on their side, with Java 8, Guava, or whatever else.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/ReactiveX/RxKotlin/issues/80#issuecomment-270271232, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEUCD2i4HmwWEe9458-ye110sFGFFks5rOvJKgaJpZM4JtuBX .

[thomasnield]

Ah that makes sense now, okay I'll drop it then.

[stepango]

Working on it https://github.com/ReactiveX/RxKotlin/pull/87

[tadfisher]

Should the package name change to io.reactivex.kotlin?

[stepango]

Good point. I'll think about it.

[thomasnield]

I agree that package convention would be better.

[JakeWharton]

The package name must change along with the Maven coordinates to ensure that both can be used simultaneously.

[thomasnield]

See #95 for 2.0 candidate codebase.

[JakeWharton]

Wow 2.x looks surprisingly good! Just did a quick review and the only thing that sticks out is the joinToString stuff which seems out of scope.

[thomasnield]

@JakeWharton Glad you like it! I pushed the joinToString() because I reduce emissions into a concatenation all the time. @stepango was initially questioning of the scope though as well, so if my personal needs are creeping in, I have no problem having it shot down.

The only merit I can give to it besides my anecdotal belief others might need it... it mirrors Kotlin collections and sequence's joinToString(). It seems appropriate and useful on the Rx side too.

Either way, I don't mind if we rid it.

[thomasnield]

I had another idea to consider... how about an extension function that adds 5 days to each LocalDate emission?

fun Observable<LocalDate>.addFiveDays() = map { it.plusDays(5) }

(I keed, I keed)

[thomasnield]

@JakeWharton In all seriousness, does that mean 'withIndex()' is out of scope too? One perspective we could maintain is asking whether an addition we make is an official ReactiveX operator, rather than going rogue and augmenting our own. I have no problem sticking to that practice, but what does that mean for 'withIndex()'?