Convert ByteString from/to Int8Array #386
Conversation
|
|
||
| package kotlinx.io.bytestring | ||
|
|
||
| import org.khronos.webgl.ArrayBuffer |
There was a problem hiding this comment.
This is something that should probably be addressed for all kotlinx libraries: should everyone use these built-in types, which are pretty weird considering we generally don't want anything to do with WebGL, or should they come from kotlin-wrappers, which tend to be the most used?
The question is important because the only "interop" between same types coming from different libs is unsafe-casting.
There was a problem hiding this comment.
If an ArrayBuffer originating from kotlin-wrappers needs to be converted to/from ByteString, then it should be done either in kotlin-wrappers, or in a separate library.
There was a problem hiding this comment.
It's reasonable. However I'm thinking that since most people on K/JS are using kotlin-wrappers (and most commonly its kotlin-js module), it would be a surprise to them that the code is red in the IDE when calling Int8Array.toByteString(), for example.
It's a bit of an unfortunate situation because it's all fragmented into multiple places.
-
The
org.khronos.webglpackage is explicitly documented as a wrapper for WebGL, so the question "why am I using WebGL types?" would come up fairly naturally. -
The
org.khronos.webglpackage is a remnant of the extraction (KT-35973) of DOM APIs from the stdlib, and there is also an open issue about moving away from it (KT-57303). So maybe using kotlin-wrapper types ensures better stability on the long run.
I guess the right call would be to have the Kotlin team officially say "we will all use these types for JS", and I guess being kotlin-wrappers is the most complete and up to date collection, that could be the direction. If the stdlib needs a small interop layer, its externals could be made internal.
Anyway, from my perspective, it's all good anyway, I'd just unsafeCast<T>, but it's something I wanted to mention for more clarity.
Closes #268