Anyone? I’m happy to have the response be “nope, d...
# kontributors
c
Anyone? I’m happy to have the response be “nope, don’t want it” - although a dialogue on why/why not would be great, so I and others can understand how to better kontribute!
o
Team is on New Year Holidays currently. We will get back to work tomorrow. I’ve bookmarked your post yesterday already 🙂
👍 1
m
Sorry for the spam, but I couldn't help but comment on the nice choice of words for the *k*ontribution ;)
c
Hey @orangy - back at it yet? 🙂
o
Yeah, thanks for reminder! I’d ask @[removed] to look at it please. See message above the one starting this thread.
👍 1
And may be @cy too
c
bump
Hey @orangy / @cy - any thoughts on how to best kontribute?
c
@cleishm Hi Chris. Thanks for sharing your experience and sorry for very long delay. First of all we usually don't add coroutines addons to stdlib but to kotlinx.coroutines and kotlinx-io. I'd say that there are serious concerns that prevent the code to be integrated as is. The first problem is that it is simply a clone of Java NIO (that is IMO is not that good especially in the selection part) while we would like to have more idiomatic API and for sure we need to eliminate known problems such as fragile and error-prone patterns, non-composable primitives and so on. The second obvious problem is that it is JVM-only and will be never multiplatform. On the other hand we are working on kotlinx-io and it's redesign right now and for sure we are not going to just copy
java.nio.ByteBuffer
that is well known as very error-prone so the code using it is very difficult to write and test corner cases.
c
@cy Happy to re-implement to meet the team expectations. The important part to me was the API for coroutine based channels (e.g. https://consensys.github.io/cava/docs/kotlin/0.6.0/cava/net.consensys.cava.net.coroutines/-coroutine-datagram-channel/index.html), not the use of the selector to provide the asynchronicity underlying it.
How would you suggest implementing to achieve the goals you have in mind?