`Observable.just(T value)` and `Observable.from(T t1)` are confusing

[runningcode]

Having Observable.just(T value) and Observable.from(T t1) is confusing to users of the API. It looks like calling Observable.from(T t1) calls Observable.just(T value) internally. The problem is that this method also exists: Observable.from(Iterable<? extends T> iterable). I found myself accidentally passing a list in to Observable.from(T t1)only to find that it took each item in that list and emitted it separately.

This becomes especially confusing when using generics. For example, suppose I have a class Foo<T> which calls Observable.from(T t1) internally. If I create class Foo like Foo<List<Bar>> what happens when it calls Observable.from(T t1) internally? Does it call Observable.from(T t1) or Observable.from(Iterable<? extends T> iterable)?

I suggest removing Observable.from(T t1) or renaming Observable.from(Iterable<? extends T> iterable) to Observable.fromIterable(Iterable<? extends T> iterable).

[samuelgruetter]

In RxScala, we call it Observable.items instead of Observable.from (see docs). IMHO it would be nice to do the same in RxJava.

[benjchristensen]

I'm not a fan of removing 'from(T)' this late in the game (almost to 1.0). Most of the time it is desired to itemize an Iterable. The 'just' operator is there for when it shouldn't be itemized.

/cc @headinthebox

[benjchristensen]

If we do pursue this change I'd probably do ...

• delete 'just'
• leave 'from(T)'
• change 'from(Iterable)' to 'fromIterable(Iterable)'

The thing I don't like about this is it will break most uses of 'from(Iterable)' that itemizes as most people want it to.

[benjchristensen]

By the way, the reason why it is designed the way it currently is is because an Observable is intended for itemized sequences of data. It is rare that the desired output is Observable<Iterable> instead of Observable.

Thus in the Foo case it would correctly convert T into an itemized sequence, which is what "from" is for. If a scalar response is desired that is what "just" is for.

So if Foo should emit Observable<List> then use Observable.just rather than the more common Observable.from.

[benjchristensen]

Any further comments or discussion on this? The key deterrent to changes here are:

1. Massive breaking change to eliminate from(T) or from(Iterable i)
2. The intended design of from is to itemize to Observable<T> and of just is to not itemize.

[abersnaze]

I support a change. Methods that do different things should have different names. It's currently ambiguous if the call Observable.from(new ArrayList<T>()) should return Observable<T> or Observable<ArrayList<T>>. I'm partial to not having a raw from(...) and break them out into their own methods.

• fromItems(T...)
• fromFuture(Future<T>)
• fromIterable(Iterable<T>)

and maybe 😃

• fromEnumerable(Func0<Enumeration<T>>)

[headinthebox]

I personally don't like fooXXX(XXX foo) names. That's why java has overloading. But if overloading does not work, we have no choice.

[benjchristensen]

I also don't like fromXXX method names.

I agree that the current semantics are somewhat awkward and could have been designed better. However, the cost of changing this is not worth the massive break on almost all existing applications since from is such a commonly used method signature.

I don't think this change should be made right before hitting 1.0. Eventually when 2.x is done (not anytime soon) this could be cleaned up, but in well over a year of usage by many people, this issue is the first time I'm aware of this issue being been brought up, thus I don't think the confusion is significant enough to warrant a breaking change.

[runningcode]

I would refer to Item 41 in Effective Java by Josh Bloch. Bloch warns to use overloading judiciously for this specific reason. Josh's advice would be to create methods such as @abersnaze suggested. Overloading in Java is broken.
I'll take a quote from the book for those who don't have access "A safe, conservative policy is never to export two overloadings with the same number of parameters"

[headinthebox]

I don't buy "appeal to authority figure" arguments. Just saying.

[mattrjacobs]

My 2c -

The current design is not correct, as described above. In particular, it's definitely surprising for a user that Observable.from(list1, list2) emits 2 lists, and Observable.from(list1) emits all elements of list1.

However, this seems like a severe cost in terms of migration for moderate-at-best benefit. I've been involved with keeping a large multi-language codebase up-to-date with RxJava as it evolves, and this migration would be a painful one.

My vote is to leave it as-is, and document the from(...) and just(...) Javadocs, as well as the Observable creation page with a clear explanation of how they are intended to be used.

[benjchristensen]

/cc @zsxwing @akarnokd @jmhofer @mttkay @daveray @davidmoten @daschl @gorzell and anyone else who has an opinion to share.

[abersnaze]

@headinthebox I'm not against overloads. Just overloads that do different things. There will still be plenty of overloads in my proposal:

• fromFuture(Future<T>)
• fromFuture(Future<T>, Scheduler)
• fromFuture(Future<T>, long, TimeUnit)
• fromFuture(Future<T>, long, TimeUnit, Scheduler)
• fromItems(T)
• fromItems(T, T)
• fromItems(T, T, T)
• fromItems(T, T, T, T)
• fromItems(T, T, T, T, T)
• fromItems(T, T, T, T, T, T)
  ...

@benjchristensen, @mattrjacobs: could 0.20 depreciate from(...) and friends and 1.0 delete to appease the naysayers?

[benjchristensen]

It is not the design I'm disputing, it's how badly this breaks almost all apps. Is this problem (that no one has complained about for over a year) really so bad as to warrant the breakage?

Whether the methods are deleted in 0.20 or 1.0 doesn't matter, whenever it happens the break happens (though if we do this we'd deprecated in 0.20 and delete in 1.0).