Inconsistent/non-standard naming convention of RxJava

I’ve been taking the Reactive Programming course on coursera and ran into this issue. It is too late to change the method names, but perhaps you can talk about it in the documentation so newbies don’t get confused. Future and Promise in Scala are similar to Guava’s ListenableFuture and SettableFuture respectively. (edit: I gather this is probably inherited from Microsoft’s C# library, but I can’t be bothered right this minute to register an account on codeplex)

In RxJava, the Observer trait has the methods {onCompleted, onError, onNext}. These are used to handle an event. Likewise, the *Subject classes have methods named exactly the same, but for a different purpose - emitting events.

This is inconsistent with every other use of the naming pattern onEvent out there (JS event handlers, even scala’s Future itself), which typically registers a callback to handle the event. (An equivalent convention is addEventListener, used by some Java UI libraries.) By contrast, the method for firing an event is usually named fireEvent or emitEvent or just plain Event.

Observer does not register callbacks, it is the callback, so its methods should be called {handleComplete, handleError, handleNext}. There is no direct analogy in scala (a plain Function callback takes that role in the Future ecosystem), but it is analogous to a Guava’s FutureCallback, though that suffers from the same problem.

*Subject is similarly inconsistent. It is an event source, that fires callbacks registered elsewhere, so it is analogous to a Promise. Its methods should be called {complete,error,emitNext}.

It would be good if the documentation mentioned this inconsistency in naming, perhaps even compare it with other similar libraries in a table like the one below, as a helpful guide for people to understand the concepts being discussed.

TL;DR:

• Observable, Future - registers callbacks, methods should be called onEvent(callback), or subscribe(handler)
• Observer, FutureCallback - is the callback/handler itself, methods should be called handleEvent or eventOccured
• Subject, Promise - emits the events, methods should be called event or fireEvent or emitEvent

[benjchristensen]

@infinity0 Just so you’re aware … @headinthebox is Erik Meijer from the Coursera course and the inventor of Rx.

[infinity0]

Conceptually we could capture the Observer passed into the Observable.subscribe, turn it into an ObserverHandler … In practice never once has it been confusing…

OK, for now I’ll take your word on this, since I haven’t played around enough with this stuff. I think I made a mistake in thinking that Subject is the analogue of Promise; I now see that this is an imperfect analogy. But I’ll also have a further look into the difference between operators vs subjects, the fact that they both exist seems connected to this issue.

I still think that on* evokes the event-based mental model to someone not familiar with this one. But thanks for your time, both of you, and I also hope it’s been useful for you too to practise explaining these topics.

One of the reasons why I had the {register,handle,fire} model in my head is because Future and Promises do follow this model - you have onComplete on Future to register a Function which is itself the callback, and you can call complete on the Promise to fire the event. (To avoid “callback hell”, you use map or flatMap.) When Observable was introduced as the “many items” counterpart to Future, I was expecting this model too. In fact, I might still try an exercise to define a form of Observable that is closer to the interface of Future/Promise, and see how that’s like to use.