Add Source and Sink extensions for Apple's NSInputStream and NSOutputStream

[jeffdgr8]

Modeled after JVM's InputStream.asSource(), Source.asInputStream(), OutputStream.asSink(), and Sink.asOutputStream(), add extension functions to similarly map to and from Apple's NSInputStream and NSOutputStream.

I previously submitted this PR to Okio. I've been using these extensions, along with my Okio fork, in my KMP library, pending availability in a public release.

[fzhinkin]

@jeffdgr8 thank you for the PR!

Unfortunately, I forgot to mention in the contribution guideline that the PR should be created against the develop branch, so I switched the base here. It shouldn't be a problem as master and develop are almost identical right now.

[whyoleg]

may be it make sense to also add the same functionality for NSOutputStream in one go?

[whyoleg]

just minor comments

[jeffdgr8]

may be it make sense to also add the same functionality for NSOutputStream in one go?

I'm actually looking into implementing the NSOutputStream extensions for Sink as well. I don't need these in my own project, so haven't had a need for them. I can create a separate PR, or combine with this one.

[jeffdgr8]

I went ahead and added NSOutputStream.asSink() and Sink.asNSOutputStream() extensions as well.

[whyoleg]

a little more comments/questions :)

[whyoleg]

LGTM after a fix of propertyForKey(NSStreamDataWrittenToMemoryStreamKey) behaviour
Nice job!
Though, I've not reviewed tests, mostly just scrolled...

[fzhinkin]

I'm not sure how things work under the hood when inheriting NSInputStream/NSOutputStream and calling a non-default initializer (I understand that no-arg initializer is not available here) as according to Apple's docs, these initializers aimed to instantiate some specific stream's subclass.

[jeffdgr8]

This was the only way I found to appease the requirement Unable to call non-designated initializer as super constructor, which is the error the compiler throws if you use the no-arg constructor. This seems to be a conflict between the way Kotlin and Objective-C object inheritance works, where Objective-C can return a subclass implementation as self from an init method.

I'm not sure there really should be an expected designated initializer in Kotlin for either of these classes. This is likely an interop error. In Objective-C this compiles and I'm able to construct [[MyNSInputStream alloc] init] just fine:

// MyNSInputStream.h
@interface MyNSInputStream : NSInputStream
- (instancetype)init;
@end

// MyNSInputStream.m
@implementation MyNSInputStream
- (instancetype)init {
    self = [super init];
    return self;
}
@end

It works to use either the memory or URL constructor of both NSInputStream and NSOutputStream. I figured the empty memory versions were likely to be the most lightweight. Is there some way to suppress this designated initializer requirement to call the no-arg constructor? It might also make sense to file an issue to fix the interop. Since we're overriding all of NSInputStream and NSOutputStream's public API functions and not using anything from the superclass, I think this should be safe though.

[jeffdgr8]

Related issues:

https://youtrack.jetbrains.com/issue/KT-47992
JetBrains/kotlin-native#2010

Looks like there is a workaround for disabling in custom .def interop, but this won't work for the platform interop in this case.

[fzhinkin]

Yeap, seems like there's no way to inherit streams using no-args init ctor.

[fzhinkin]

In fact, I was mostly concerned about the possibility of inheriting some methods from NSInput/OutputStream subclasses instantiated for initFromData, initToMemory. But it's definitely not the case, as there were errors due to non-implemented run-loop-related methods previously (so nothing was inherited).

[jeffdgr8]

I added the suggested doc comments. It would be strange for a consumer to call any of those init functions after receiving the instantiated stream object from asNSInputStream() or asNSOutputStream(). In Kotlin it already shows an error trying to call init functions directly, not through a constructor. I don't think I've ever seen a call to an init function even in Objective-C that wasn't directly after a call to alloc. Swift doesn't allow this either, where init functions are only usable to construct objects now.

[fzhinkin]

Thanks for updating the doc! Yes, it should be possible to call these initializers only from Objective-C code and it seems like nobody actually does that, but it is still possible :')

[fzhinkin]

@jeffdgr8 thank you for fixing all the issues!
Right now there are only two questions left:

• one with exhausted called in read (Add Source and Sink extensions for Apple's NSInputStream and NSOutputStream #174 (comment))
• one with inheritance from particular stream's subclass (Add Source and Sink extensions for Apple's NSInputStream and NSOutputStream #174 (comment))

I'll try to figure out if anything could be done with the latter (and if there's nothing we can do - I'm fine with how it's done right now).
Otherwise, the change looks good.