Bump to RxJava 1.1.5

[zsxwing]

• Bump to RxJava 1.1.5
• Add missing operators

[samuelgruetter]

I see that more and more xxxDelayError methods are added, and the number of methods in the API becomes bigger and bigger. Currently there are 8 of them:

  def concatDelayError[U](implicit evidence: Observable[T] <:< Observable[Observable[U]]): Observable[U]
  def concatMapDelayError[R](f: T => Observable[R]): Observable[R]
  def switchMapDelayError[R](f: T => Observable[R]): Observable[R]
  def switchDelayError[U](implicit evidence: Observable[T] <:< Observable[Observable[U]]): Observable[U]
  def mergeDelayError[U >: T](that: Observable[U]): Observable[U]
  def flattenDelayError[U](implicit evidence: Observable[T] <:< Observable[Observable[U]]): Observable[U]
  def flattenDelayError[U](maxConcurrent: Int)(implicit evidence: Observable[T] <:< Observable[Observable[U]]): Observable[U]
  def combineLatestDelayError[T, R](sources: Iterable[Observable[T]])(combineFunction: Seq[T] => R): Observable[R]

Will there be even more later?
Do you think we could treat all of these in a more uniform way? Maybe by adding an ErrorDelayingObservable containing all these methods, and a toErrorDelaying method, in the same way as we have a BlockingObservable? Or maybe give these methods a boolean argument with default value: delayError: Boolean = false? Or something else? Or is this too much complication for what we gain? Also, do you know if this has been discussed in RxJava, and what was decided for RxJava?

[zsxwing]

Maybe by adding an ErrorDelayingObservable containing all these methods, and a toErrorDelaying method, in the same way as we have a BlockingObservable

It will become too verbose for RxJava considering Java doesn't have the extension methods.

Or maybe give these methods a boolean argument with default value: delayError: Boolean = false?

Java doesn't have the default value.

However, both them are supported in Scala.

For the default values, I remember when we use overload, default value, currying and implicit together, the compiler will be crazy and not be able to resolve the correct method. So I prefer the extension method idea.

[samuelgruetter]

I'm a bit confused, why you are mentioning extension methods? Do you mean extension methods as defined here? The approach used in BlockingObservable does not require extension methods at all.

[zsxwing]

Yep. toErrorDelaying is too verbose so I suggest to use the extension methods.

[samuelgruetter]

Ok, but what if we call it .delayError instead of toErrorDelaying? Then, instead of myObservable.concatMapDelayError(myFunc), we'd write myObservable.delayError.concatMap(myFunc), which has exactly the same amount of letters. What do you think about this?

[zsxwing]

Sounds great. I will update the PR.

[zsxwing]

combineLatestDelayError is still in Observable object.

[samuelgruetter]

Yeah, I guess Observable.combineLatestDelayError is better than ErrorDelayingObservable.combineLatest (unless there will be many more static xxxDelayError methods, maybe)

[zsxwing]

@samuelgruetter updated.

[samuelgruetter]

should be concat instead of concatDelay, I guess?

[zsxwing]

should be concat instead of concatDelay, I guess?

Fixed

[samuelgruetter]

LGTM