rcmkt
commented
2 years ago Initially, core module is written in pure kotlin to allow working with elmslie in pure java and kotlin. Also, this mr would require coroutines dependency when working with RxJava. What is the motivation behind rewriting the core module with coroutines?
Hi @diklimchuk! We had lots of discussions about further development of the lib and features that nice to have and we corrected the main focus with the following points: 1) With the current implementation (pure kotlin/java primitives), it's a way harder to develop the next features. For example the coordinators much harder to review and understand the internals and how to use them in the client's code. On the other hand, using coroutines in the core much simplify the further redesign and development. 2) You said about external dependency. In the real world, coroutines dependency is already existed in all projects. Android/Compose brings them implicitly. We decided to focus on kotlin users so it's ok to include it. 3) We're preparing the basement for Kotlin Multiplatform and as you know the coroutine is a loyal ally in this regard. 4) Version 2.0 - can use pure java way and develop independently. We don't think it's an issue. A lot of libraries use this approach.
Сheck the branch, it looks nice, does it?) And what do you think?
Initially, core module is written in pure kotlin to allow working with elmslie in pure java and kotlin. Also, this mr would require coroutines dependency when working with RxJava. What is the motivation behind rewriting the core module with coroutines?