2.x: Observable.compose naming

[davidmoten]

Observable.compose(Transformer) has always struck me as an odd combination.

I'd expect us to compose with a composer or transform with a transformer. My preference would be to use

Observable.transform(Transformer).

Anyone up for this change in 2.x?

[akarnokd]

How about inlining Transformer as Function<? super Flowable<T>, ? extends Publisher<? extends R>>?

[JakeWharton]

👍 on the operator method rename.

@akarnokd You're saying only on the method parameter type? So we'd keep the public API interface for convenience but accept the more liberal version on the method?

[akarnokd]

I'm saying let's keep it as compose.

[dalewking]

On the subject of compose and the use of Function as its parameter type, this is kind of problematic in the real world. It would be very nice to be able to create an object that can be used to transform Observables, Flowables, Singles, Completables, and now Maybes. In other words, to have a single object instance that can be passed to any of the compose methods (Observable.compose and Single.compose and so on).

This however cannot be done because it would require having an object that extended from Function multiple times with different type arguments. (See this discussion on how it affects the RxLifecycle library and how we worked around the issue trello-archive/RxLifecycle#39).

It would be really nice if RxJava 2 could address this some how. Perhaps it would require having two versions of the compose method. One that takes the more generic Function type as a parameter and another one that takes a type specific interface that does not implement Function.

[akarnokd]

Naming it transform feels odd to me, mostly because Guava's FluentIterable called its map as transform. If you want to change the functional interface to be unique then go ahead with a PR.

[akarnokd]

I'm closing this issue due to inactivity. If you have further input on the issue, don't hesitate to reopen this issue or post a new one.