Shorter naming for .toBlockingObservable()

[daschl]

Hi folks,

I'm exposing Observables to my user, and while this is awesome I'm realistic and know that a lot of them will fall back to blocking immediately either because they are migrating their blocking codebases or they just can't handle it properly.

While I think how RxJava exposes blocking is good, I think there is also room for improvement to make it shorter. For example, consider the following:

Cluster cluster = new CouchbaseCluster("127.0.0.1");
Bucket bucket = cluster.openBucket().toBlockingObservable().single();

Document doc = JsonDocument.create("hello", JsonObject.empty().put("Hello", "World"));
bucket.upsert(doc).toBlockingObservable().single();

System.out.println(bucket.get("hello").toBlockingObservable().single());

Especially if you are dealing a lot with just a single value, something like await() on the observable would be good, or some shorter way/alias name. To be honest I'm not sure if this is possible, but I also thought about shipping a helper class which just wraps the calls like BlockingUtils(observable).single() or something like this.

[daschl]

@benjchristensen wdyt?

[benjchristensen]

We specifically chose the explicit and long name toBlockingObservable so people are fully aware of what they're opting into. We also consciously moved all of the blocking operators out of Observable into BlockingObservable so it is very clear what operators are blocking and which are not.

You can however use BlockingObservable.from(o) which would be the same as BlockingUtils(observable).

The await name isn't quite right, as the method itself is not awaiting anything, it's just giving access to the blocking methods that would await.

We could suggest to the broader group to alias something shorter like .blocking() or .toBlocking() to .toBlockingObservable(). Then it would be like this:

System.out.println(bucket.get("hello").blocking().single());

[daschl]

@benjchristensen makes sense! I really like .blocking() it is much more concise. Can you bring that to a vote?

[chrisjenx]

+1 for Alias, toBlocking() and toBlockingObservable()

[daschl]

@chrisjenx what do you think about just blocking()?

[chrisjenx]

@daschl I think it needs to remain clear that its is to a blocking Observable, as blocking() to me implies its an operator, which it is not.

[benjchristensen]

@headinthebox @akarnokd @abersnaze @zsxwing Any issues with aliasing .toBlocking() for .toBlockingObservable() to keep it shorter?

[akarnokd]

.toBlocking() is fine with me.

[zsxwing]

toBlocking +1

[daschl]

I submitted a (simple) PR for this in case we get consensus.

[headinthebox]

I vote no, strongly. Autocomplete will type it for you. And as Ben says, it should be there as a blinking danger sign to war you that you are doing something unsafe. That why in Haskell unsafePerformIO has such a long name.

If you want to make it shorter, I propose .BLOCKING(), all caps.

[daschl]

@headinthebox not sure I can follow. While I can understand that it breaks the idea of async flows, lots of applications, sooner or later at the end of the chain will fall back to blocking so they can return it to a servlet or whatever.

I don't think we should make it hard on people, sync programming is a legit concept, even if it is not as powerful as Rx.

[daveray]

I also vote no. BlockingObservable.from() is sufficient and avoids auto-complete-induced temptation. Ideally if you need blocking, it's in a single, generic spot so it shouldn't even come up that often.

[benjchristensen]

@daschl won this one :-)

We have deprecated toBlockingObservable() in favor of toBlocking() which is less annoying to use while still being clear, and will better match the pattern with toParallel() that will come one day when I get around to it.

[benjchristensen]

See #1233 for the change.

[daschl]

@benjchristensen thanks for taking care of it. My users will appreciate it.