Rename OperatorMulticast and OperatorMulticastSelector?

[davidmoten]

Was looking at the source of OperatorMulticast and OperatorMulticastSelector and neither implements Operator. Is a rename in order here or are they going to be made into Operators soonish?

[akarnokd]

They can't be operators because they need to be ConnectableObservables. I think the naming is just stuck so they don't stand out of the other OperatorXYZ classes. Btw, there are a bunch of OperatorXYZ which implement OnSubscribe only yet they are called Operator.

[davidmoten]

Yep you're quite right, of the 93 Operator* classes in the operator package, roughly 22 do not implement Operator. This is a lot of hiding though perhaps some are candidates to implement Operator in the near future. Why not rename everything that is not an Operator (and not a candidate for conversion to Operator)? Might prompt a new package or two to contain these beasts. In the case of the classes above I'd prefer to see them as ConnectableObservableMulticast and ConnectableObservableMulticastSelector.

[davidmoten]

Here's a quick list, might have missed some:

OperatorAmb.java:public final class OperatorAmb<T> implements OnSubscribe<T>{
OperatorCache.java:public final class OperatorCache<T> implements OnSubscribe<T> {
OperatorCombineLatest.java:public final class OperatorCombineLatest<T, R> implements OnSubscribe<R> {
OperatorDefer.java:public final class OperatorDefer<T> implements OnSubscribe<T> {
OperatorDelay.java:public final class OperatorDelay<T> implements OnSubscribe<T> {
OperatorDelay.java:    public static final class Emitter<T> implements OnSubscribe<T>, Action0 {
OperatorDelaySubscription.java:public final class OperatorDelaySubscription<T> implements OnSubscribe<T> {
OperatorDelayWithSelector.java:public final class OperatorDelayWithSelector<T, U, V> implements OnSubscribe<T> {
OperatorGroupJoin.java:public final class OperatorGroupJoin<T1, T2, D1, D2, R> implements OnSubscribe<R> {
OperatorJoin.java:public final class OperatorJoin<TLeft, TRight, TLeftDuration, TRightDuration, R> implements OnSubscribe<R> {
OperatorMulticast.java:public final class OperatorMulticast<T, R> extends ConnectableObservable<R> {
OperatorMulticastSelector.java:public final class OperatorMulticastSelector<TInput, TIntermediate, TResult> implements OnSubscribe<TResult> {
OperatorParallelMerge.java:public final class OperatorParallelMerge {
OperatorRefCount.java:public final class OperatorRefCount<T> implements OnSubscribe<T> {
OperatorReplay.java:public final class OperatorReplay {
OperatorSequenceEqual.java:public final class OperatorSequenceEqual {
OperatorSkip.java:public final class OperatorSkip<T> implements Observable.Operator<T, T> {
OperatorTakeUntil.java:public final class OperatorTakeUntil {
OperatorTimerOnce.java:public final class OperatorTimerOnce implements OnSubscribe<Long> {
OperatorTimerPeriodically.java:public final class OperatorTimerPeriodically implements OnSubscribe<Long> {
OperatorToMap.java:    public static final class DefaultToMapFactory<K, V> implements Func0<Map<K, V>> {
OperatorToMultimap.java:    public static final class DefaultToMultimapFactory<K, V> implements Func0<Map<K, Collection<V>>> {
OperatorToMultimap.java:    public static final class DefaultMultimapCollectionFactory<K, V>
OperatorToObservableFuture.java:public class OperatorToObservableFuture {
OperatorUsing.java:public final class OperatorUsing<T, Resource extends Subscription> implements OnSubscribe<T> {

[akarnokd]

These operators are considered internal implementation and unless you are a hard-core rxjava-core developer, you don't need to worry about what is in rx.operators. Many of these operators don't implement Operator because the behavior they need to perform can only be done while in OnSubscribe.call(); there is no one to pass a Subscriber further up since they behave basically as sources.

[benjchristensen]

The ones that implement OnSubscribe could be renamed from Operator* to OnSubscribe*.

More importantly though, these should never be relied upon publicly. They are not part of the public API and can change at any time, even once we hit 1.0.

[davidmoten]

So I don't have hard core understanding of the rxjava code base but I'm using it on a a lot of projects at work and to develop with rxjava I very frequently dig small holes into the source code to understand what I'm using and I use the source as a cookbook. I can't imagine developing with the library without the source code. Given that I'd like to see those spades called spades to minimize a bit of possible confusion (e.g. why is Observable.create being called with an Operator, what overload is that?).

Happy to knock up a pull request if this has support.

[benjchristensen]

I'm okay with a change that makes the OnSubscribe implementations start with OnSubscribe.

So that this is clean, please do not mix any other changes with it, just renaming those ~20 files that should start with OnSubscribe instead of Operator.

Example OperatorAmb -> OnSubscribeAmb

@akarnokd Do you have an issue with this? It seems to be clearer, and matches the intent of of classes such as OnSubscribeRange and OnSubscribeFromIterable already there.

[headinthebox]

LGTM

[akarnokd]

For me, using Operator as prefix is simpler so no need to remember the base interface for each operator. I'd even drop the prefix but I guess that would just complicate auto-complete in IDEs.

[benjchristensen]

These classes are internal and referenced from a single place, Observable so I'm fine either way. I think we should either give them a completely generic prefix (I can't think of one right now) or make the OnSubscribe* and Operator* prefix consistent as suggested in this issue.

[davidmoten]

The generic prefix idea is not attractive to me because I lose visibility at a glance of what types the classes are. I end up in the same place as I am now. Dropping the prefix would do the job if we moved non-operators out of the operator package to an onsubscribe package. My preference at the moment is Operator -> OnSubscribe.

[benjchristensen]

I'm fine with you changing the prefixes if you want to contribute that.

[headinthebox]

Sounds good.