Order of subscribeBy parameters is not the same as standard RxJava's subscribe

[BoD]

With standard RxJava, you can do:

mySingle
    .subscribe ({ result -> println(result) }, {e -> e.printStackTrace()})

so one would suppose that with RxKotlin you could do

mySingle
    .subscribeBy({ println(it) }, { it.printStackTrace() })

but in fact, this is not possible, because the first parameter is onError, and the second one is onSuccess, which is the opposite of the order you have on RxJava's subscribe.

Because of this, you are forced to use named parameters like this...

mySingle
    .subscribeBy(onSuccess ={ println(it) }, onError={ it.printStackTrace() })

That's too bad :(

But it's even more confusing if you pass only one parameter. One would expect that it would be onSuccess (line standard RxJava method that takes only one parameter), but in fact it's onError, which is very counter intuitive and surprising.

[thomasnield]

I think I reversed the order for that reason that passing one nameless parameter attached to the onSuccess(). Now if this isn't the case anymore, it needs to be investigated and possibly changed.

[JakeWharton]

It is the case. The best way to solve this would be overloads though.

…

On Wed, Mar 7, 2018 at 3:16 PM Thomas Nield ***@***.***> wrote: I think I reversed the order for that reason that passing one nameless parameter attached to the onSuccess(). Now if this isn't the case anymore, it needs to be investigated and possibly changed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#174 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEUszAfs3i_w3tstpbUsUUSve6ykzks5tcD5HgaJpZM4SbDZ9> .

[BoD]

I'm sorry, I don't understand this sentence "I think I reversed the order for that reason that passing one nameless parameter attached to the onSuccess()."

[thomasnield]

@BoD Try this and you should see it works with the current setup:

mySingle.subscribeBy { result -> println(result) }

@JakeWharton and yes, overloads are probably the most effective way to fix this. Accepting PR's from anyone as I'm kind of busy right now.

[BoD]

You are right, it works indeed, so the last part of what I wrote is incorrect. I can't figure out right now what I did that made me think the single parameter was onError... Weird!

[grabstepango]

Don't think there is any problem here. Passing multiple lambdas in one function would any way benefits from named parameters.

[arekolek]

You are right, it works indeed, so the last part of what I wrote is incorrect. I can't figure out right now what I did that made me think the single parameter was onError... Weird!

@BoD Because

mySingle.subscribeBy { result -> println(result) }

is not the same as

mySingle.subscribeBy({ result -> println(result) })

In Kotlin, there is a convention that if the last parameter of a function accepts a function, a lambda expression that is passed as the corresponding argument can be placed outside the parentheses

I thought the order of arguments of subscribeBy was intentional, because it's convenient to do stuff like:

mySingle.subscribeBy(Timber::e) { result -> println(result) }

[omeryounus]

Umm I don't understand how these working, I never found onError throwing any errors. Its seems like its just there for no reason