Revisit ExperimentalObservable
zsxwing opened this issue · comments
I just found one issue about the idea of ExperimentalObservable
. If we want to move some mature method from ExperimentalObservable
to Observable
, we have to break the binary compatibility. Thoughts on how to solve it, or this is not a good idea and we should use RxJava's @Beta/@Experimental
?
Another disadvantage of ExperimentalObservable
is that because overload
and implicit conversion
cannot work together, sometimes we need to rename the method to make the compiler happen. See #151
Maybe we should just move everything from ExperimentalObservable
into Observable
. The only problem then is how to mark it, because AFAIK, method annotations are not shown in scaladoc. But we could just mark the experimental methods in the documentation, maybe with the same red badge as here, but put it per method instead of per class. That's just one line of HTML, should be easy to use.
I did some work to update to RxJava 1.0.10, which adds a bunch of @experimental methods to Subject. I followed the example of ExperimentalObservable, which in this case meant adding ExperimentalSubject, ExperimentalAsyncSubject etc. which felt a bit unwieldy.
Start using @Experimental/@beta in RxScala as well might be the better solution.
Also, I looked into adding RxScala support for the proposed AbstractProducer, which meant adding an object ExperimentalObservable for the create()/apply() methods. Moving those methods later would mean breaking source compatability as well.
OK. Let's move everything to Observable
and use @Experimental/@Beta
.
Looks some css style bug in the Scala doc. The EXPERIMENTAL labels in this page are really weird: http://www.scala-lang.org/api/2.11.6/scala-reflect/index.html#scala.reflect.api.package
Closed. It's resolved in 0.25.0.