Does anybody have experience with maintaining both...
# coroutines
e
Does anybody have experience with maintaining both coroutine-based and non-coroutine-based codebases in a library? I.e. marking a random library method with
suspend
is a breaking change, since the callers now have to wrap it inside a coroutine builder. Ideally I'd like library users to opt into coroutines if they decide to and be able to use the library as is if they don't, and avoid duplicating code add coroutines support. Any OS projects that do this already?
r
I think the only way which is backward compatible is to have a new coroutines-based suspend function, with the existing signature using
runBlocking
and wrapping the new suspend function.
Callers can continue to use their existing function which transparently uses the builder, or call the new suspending function.
e
nice, thank you! that's a valid approach, however, the naming also becomes hard, i.e. you'd need to have
retry()
and smth like
retrySuspendable()
, which is not perfect
r
Agreed, naming is an issue.
e
I think I like
retry()
vs
retryBlocking()
r
That's what I ended up doing in my case, but isn't possible to use that naming to keep things backward compatible for an existing library.
e
makes sense
p
You have
Async
in arrow precisely for this use case of bridging frameworks
ping me privately if you're interested and I can give you an intro and some resources 🙂
r
@pakoito Not the same case as I understand it.
p
I'm pretty sure it is, opting into coroutines or running with other abstractions, with assurance there will or will not be thread jumps
and generally avoiding having to explicitly call the coroutines version of
async
or
launch
in libraries
j
arrow library discusses polymorphic program article which may be helpful: https://arrow-kt.io/docs/patterns/polymorphic_programs/
👍 3
k
Would be a good blog article @pakoito
p
the doc @Jeremy Rempel linked sums it all up quite nicely. It’d be hard for me to explain it in fewer words