That's pretty standard for InputStream, at least

# squarelibraries

[jw]

That's pretty standard for InputStream, at least

[Jeff Lockhart]

That should be acceptable, copying bytes as they're read. I'm similarly copying ByteArray to NSData with other platform type conversions.

I'd be happy to take a stab at implementing a solution. Just need to familiarize myself with the code first. Feel free to share any guidance or suggestions.

[Jeff Lockhart]

Here's a quick pass at java.io.InputStream.

SourceInputStream.kt

[jw]

Okio has that built in

[jw]

It's only the NS one we don't have

[Jeff Lockhart]

I only see an API for BufferedSource.inputStream(), but not Source.inputStream(). Is that what you're referring to? Perhaps BufferedSource is the appropriate unifying API for java.io.InputStream and NSInputStream.

[jw]

If you only have a Source you can trivially get a BufferedSource by calling buffer()

[Jeff Lockhart]

Ok, so it seems it would make sense for the API to accept any Source, then in the platform implementations, call buffer().inputStream() to convert to java.io.InputStream or NSInputStream.

Since the appleMain source set inherits BufferedSource from the nonJvmMain source set, would it make sense to implement BufferedSource.inputStream(): NSInputStream as an extension function?

[jw]

Buffering should never be an implementation detail of calling a function. We always want to promote that to the caller

[jw]

You can write it as an extension function but it will not be available to call from Swift or Objective-C then. See https://github.com/square/okio/issues/1113 for another example gone awry

[Jeff Lockhart]

Ah, that answers some of my next line of thought. I'm assuming decoupling the appleMain source set from the nonJvmMain actual declaration of BufferedSource would be non-trivial, which is what would allow it to work similar to the jvmMain implementation, adding the additional inputStream() function to the interface.

Besides the default implementation route, I was also thinking how it could be nice for source sets to override an inherited actual declaration with their own more granular version.

[Jeff Lockhart]

For my use case, I only need the extension in Kotlin though. The code I'm working on is a KMM wrapper API for a database, which mirrors the JVM database API with Kotlin expect declarations.

The actual implementations for android either typealias to the underlying SDK or call through to the underlying, when typealias is inadequate.

The ios actual implementation similarly calls through to the ObjC SDK, massaging the underlying API to align with the Kotlin definition and converting between platform types.

[Jeff Lockhart]

Although, I could see how an extension could be useful when utilizing the database API in Swift/ObjC if the user wished to use an Apple native NSInputStream instead of okio's Source API. But it wouldn't be a strict requirement to provide such an API.

[Jeff Lockhart]

For the most part, users would be consuming the API in a KMM module in Kotlin though.

[Jeff Lockhart]

Would also want to avoid actually converting between streams multiple times anyway, considering the data copying required.

[Jeff Lockhart]

Here's a crack at BufferedSource.inputStream(): NSInputStream.

BufferedSource.kt

[Jeff Lockhart]

And here's NSInputStream.source(): Source. In this direction, you can actually avoid the data copy, as ByteArray can be written to as a CPointer.

Source.kt

[Jeff Lockhart]

I added some tests with these NSInputStream additions on this branch. Let me know what you think. I can make a PR.

[jw]

I'm definitely not experienced enough in the semantics of the darwin APIs, but it looks good from a cursory glance.

[Jeff Lockhart]

Cool, here's the PR. I appreciate your help.