Update to using RxJava 1.0.11

[jbripley]

Major changes:

• Moves Beta/Experimental methods into Observable from ExperimentalObservable. Most overloaded methods now have the same name as in RxJava, now that they're no longer implicitly defined.
• Adds new RxScala methods for Beta/Experimental methods added in Observable and Subject in RxJava 1.0.10/1.0.11

Issues:

• Currently missing Experimental method Subject.getValues(Array[T]), since I'm not good enough at generics to get a Scala version compiling. Due to Array being invariant in Scala and covariant in Java. This is closest I've gotten:

@Experimental
def getValues[U >: T](a: Array[U]): Array[U] = { // use U >: T because Array is invariant
  val us: rx.subjects.Subject[U, U] = asJavaSubject.asInstanceOf[rx.subjects.Subject[U, U]]
  us.getValues(a)
}

Which does not compile:

Error:(145, 8) overloaded method value getValues with alternatives:
(x$1: Array[U with Object])Array[U with Object] <and>
()Array[Object]
cannot be applied to (Array[U])
  us.getValues(a)

• using(=> Resource)(Resource => Observable[T], Resource => Unit, Boolean) => usingWithDisposeEagerly and flatMapWith(T => Observable[U])((T, U) => R)(Int) => flatMapWithMaxConcurrent, needed to be renamed to not conflict with existing methods.

[zsxwing]

@jbripley I sent jbripley#1 to fix some issues in this PR. Could you take a look and merge it?

[zsxwing]

See http://code.iamzsx.me/RxScala/#rx.lang.scala.Observable for the experimental/beta labels.

[samuelgruetter]

flatMapWithMaxConcurrent is a very ugly name, can't we change it to just flatMapWith if we put the maxConcurrent argument as first argument? This should also be simpler to read, because the maxConcurrent argument is much shorter than the lambdas passed to the method.

[samuelgruetter]

@zsxwing nice work for the experimental/beta labels, but I guess you did not yet add all? For instance, def flatMap[R](f: (T) ⇒ Observable[R], maxConcurrent: Int): Observable[R] has an @Beta annotation, but no red label in http://code.iamzsx.me/RxScala/#rx.lang.scala.Observable.

[zsxwing]

@samuelgruetter updated the rest methods

[jbripley]

@samuelgruetter I agree that flatMapWithMaxConcurrent is ugly and I went with your suggestion of putting the maxConcurrent parameter first instead, so we can name it flatMapWith.

@zsxwing I agree with your changes and the Beta/Experimental graphical Scaladoc annotations are really nice. Some of the BlockingObservable Scaladoc cleanup doesn't really have anything to with the RxJava update, but I'll let that slide :)

I'm in no hurry to add Subject.getValues(Array[T]). A getter with side-effects doesn't feel very Scala to me. Are we fine with leaving it out for now?

[samuelgruetter]

@samuelgruetter I agree that flatMapWithMaxConcurrent is ugly and I went with your suggestion of putting the maxConcurrent parameter first instead, so we can name it flatMapWith.

I actually meant to put the maxConcurrent argument at the first position in all methods which take such an argument, but I guess I wasn't very precise... ;-) Currently it's inconsistent and I don't like that.

I'm in no hurry to add Subject.getValues(Array[T]). A getter with side-effects doesn't feel very Scala to me. Are we fine with leaving it out for now?

Yes, let's leave that out.

[zsxwing]

I'm in no hurry to add Subject.getValues(Array[T]). A getter with side-effects doesn't feel very Scala to me. Are we fine with leaving it out for now?

I don't think we really need it. Let's leave it out until someone requires it.

[headinthebox]

It is horrible design even in Java ;-)

[zsxwing]

@jbripley another pr to make the deprecated messages more friendly: jbripley#2

I actually meant to put the maxConcurrent argument at the first position in all methods which take such an argument

+1. @jbripley I also propose that let's keep the old methods and deprecate them if possible. Since we can just deprecate them and maintain the backward compatibility, let's do it in 0.25.0. So that the users will have enough time to update their codes. We can remove them in 0.26.0.

[jbripley]

@samuelgruetter @zsxwing Ok, I'll change all flatMap related methods that use maxConcurrent to put it as first parameter and deprecate the old ones. Do we prefer ex. flatMap(T => Observable[R], Int) to flatMap(Int, T => Observable[R]) or flatMap(Int)(T => Observable[R])?

[samuelgruetter]

The decision whether to choose flatMap(Int, T => Observable[R]) or flatMap(Int)(T => Observable[R]) should be guided by how "usable" they are, i.e.

1. How well do type parameter inference, lambda argument inference, and overloads resolution work?
2. How nice/readable is code using these flatMap methods?

[jbripley]

@zsxwing I spent like an hour trying to get the deprecated flatMapWithMaxConcurrent Scaladoc links to work, but couldn't figure it out. Could you take a look?

[zsxwing]

@zsxwing I spent like an hour trying to get the deprecated flatMapWithMaxConcurrent Scaladoc links to work, but couldn't figure it out. Could you take a look?

@jbripley, see jbripley#3
It's really painful to use Scaladoc links :(

[zsxwing]

@jbripley jbripley#4 this is my last suggestion for this PR. Others LGTM. @samuelgruetter could you take a final look?

[samuelgruetter]

[...] so we can avoid to use currying.

@zsxwing so you prefer the uncurried version, and would consider currying only if it improves type inference?

I'm not (yet) sure whether I find the curried version nicer:

Compare

.flatMap(
   maxConcurrent = 10,
   v => ...
)

to

.flatMap(maxConcurrent = 10){ v =>
   ...
}

[zsxwing]

@samuelgruetter I like all flatMap methods are consistent. We cannot use currying for the following methods because of the conflicts

def flatMap[R](maxConcurrent: Int, f: T => Observable[R]): Observable[R]
def flatMap[R](maxConcurrent: Int, onNext: T => Observable[R], onError: Throwable => Observable[R], onCompleted: () => Observable[R]): Observable[R]

So I would like to use def flatMapWith[U, R](maxConcurrent: Int, collectionSelector: T => Observable[U])(resultSelector: (T, U) => R): Observable[R] to make it consistent with the above flatMap methods.

[samuelgruetter]

@zsxwing you're right, I forgot that overload resolution only looks at the first parameter list.

LGTM.

[zsxwing]

Thank you :)