Re: [boost.async] new name

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2023-10-12 06:04:52

czw., 12 paź 2023 o 07:26 Klemens Morgenstern <
klemensdavidmorgenstern_at_[hidden]> napisał(a):

> > Anything with an underscore in it is an instant no from me.
>
> Why?
>
> >
> > While you didn't ask for it, let me offer some thoughts about the naming
> rather than a yes/no.
> >
>
> Any help is appreciated. Naming is the second hardest task in software
> development after all.
>
> > I understand that your library is a *frontend* for asynchronous
> computations, rather than a backend. A thing like Boost.ASIO or another
> executor would be a backend. Is that a correct characterization? If yes,
> "async.core" sends an opposite message: as if it was a backend.
> >
>
> Well the idea there is that I enthusiastically hope for more libraries
> using my coros, e.g. async.http. Hence core would be the core library
> of a bunch of async.* libs.
> But I guess that is based on high hopes on my end with the additional
> big question of whether or not people writing those libraries would
> even want to do that. beast isn't named asio.http either.
>
> > The introductory sentence in GitHub say:
> >
> > This library provides a set of easy to use coroutine primitives &
> utilities running on top of boost.asio. These will be of interest for
> applications that perform a lot of IO that want to not block unnecessarily,
> yet still want to have linear & readable code (i..e. avoid callbacks).
> >
> > One could summarize it even shorter as "a set of awaitables and basic
> algorithms on them". In this spirit the name "Boost.Awaitables" would
> reflect this, "await" (as a verb) a bit less so.
> >
>
> Well I don't like awaitable, as it's something that can be awaited.
> But my lib provides the things that await as well, so it would be
> boost.awaiters. Which is also weird, hence the idea of `await`.
>

I would think "awiatable" is like an iterator: an interface between two
parties: one party exposes the interface, the other party consumes the
interface. I like the usage of "await" as it sends the message "out of many
ways for doing asynchrony, we propose one based on awaitiables". Maybe
other grammatical forms of "await" is an option:

Boost.Awaits
Boost.Awaiting

>
> >
> > "co_async" does reflect that it will have something to do with C++
> coroutines, but doesn't say what. If you wanted to say "the subset of
> usages of coroutines that deal with asynchrony", you are losing it. It
> looks more like "a better version of boost::asio::co_spawn". "cosync" no
> longer associates with C++ coroutines because of the missing underscore. I
> read this as "cosine".
>
> And co_sync would have the same issues as co_async?
>

I wonder how we get from "async" to "sync". Does co_sync imply "it is no
longer 'sync' because it is now 'co_'"?

Regards,
&rzej;

>
> >
> > "co20" is so strange that it could actually do the trick. It would fit
> into the same category as Boost.Spirit, Boost.Phoenix, Boost.Beast: it's
> just a cool name, if you want to learn what the library is for go to the
> documentation. But you might as well go with Boost.Zen.
>
> Well plus I don't like version numbers in libraries. A few standards
> down the line, they seem out of date and as if they only were for this
> version. Now I know better in the case of boost.mp11 for example, but
> new users might not.
> But I guess that it's coro with r -> 2, so co2o, isn't as obvious as i
> hoped.
>