Also, <@U2E974ELT>, what about the general naming ...
# coroutines
v
Also, @elizarov, what about the general naming for coroutine builders? AFAIR, the initial idea was to create an API which would feel somewhat like language constructs. That would imply using short one-syllabic names for coroutine builders and scoping functions, but now we have monsters like
runBlocking {}
, etc. Can't we rename that into
blocking {}
?
e
voddan:
blocking
was one of the original naming options. We've decided to use longer, scarier name (because it is scary -- it blocks a thread), while also making clearer what it does -- it "runs" the block of code similar to the stdlib's
run
, but it also blocks your thread. Hence
runBlocking
.
v
IMO the reference to
run
is very obscure and hardly adds any clarity (in my opinion, again)
The cool thing about
run
,
with
is that they look like language constructs. And now we add "run's little brother"
runBlocking
which does not fall into that category , hence destroying the whole illusion
e
We also wanted a verb there, but
blocking
is not a verb, while calling it
block
would be confusing, too. That was another original reason in favor of
defer
(which is a verb) vs
async
(which is not), but
async
is way more recognizable, indeed, while
defer
, as it turns out, is not even known as a verb to less English-savvy people.
Blocking your thread should really stand out, like a sore thumb. It should not be elegant.
v
mne, IMHO anything that is used often enough should be elegant
e
It is a pain that so many standard JDK methods with nice and short names would actually block your thread.
Future.get()
anyone?
It considerablely increases complexity of writing async code in Java. Lot of work on tooling is needed.
v
Methods and stand alone scoping functions are different in my head for some reason. For example I am okey with
forEach
(method), but would not be okey with anything but
repeat
(stand alone scoping function)