Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bridging to CoreFoundation types for InputStream/OutputStream #607

Closed
wants to merge 1 commit into from

Conversation

apocolipse
Copy link

Relies on #605 for fixes to spelling.

Adds proper bridging to InputStream and OutputStream to their CF counterparts.

@phausler
Copy link
Contributor

This seems ok, but what is the exact use case here? the CF bridge protocols are internal only. Is this somehow intending to allow Foundation's OutputStream to be passed/fetched directly to/from CF as a CFWriteStream?

@apocolipse
Copy link
Author

@phausler Yes, intending to allow direct access to CFWriteStream (and read), Currently there's a discrepancy between CFStreamPropertyKeys and Stream.PropertyKeys such that if you want to set specific keys it must be done on a CF stream, and vice versa. i.e. Stream.PropertyKey.socketSecuritylevelKey is implemented but not for CFStreams. As well as things like CFStreamCreatePairWithSocketToHost are not implemented for Stream (yet).

Ideally, all of the Stream.PropertyKeys should eventually align with all kCFStreamPropertyKeys, and utilities like getStreamsToHost in Stream will be fully implemented (#588 #589) so that lower level CFStream , but for now bridging helps get around some of the current inconsistencies.

@apocolipse
Copy link
Author

@phausler are you indicating this won't allow for external bridging? If not, is there any way that will? Otherwise I'd opt to just expose the internal _cfObject and init(reference:)

@phausler
Copy link
Contributor

CF is an internal implementation detail of swift-corelibs-foundation. I often attempt to dissuade Swift developers from using CF - because it is quite painful to deal with typing unsafe so many times and often the Foundation counterparts are faster anyhow.

In this particular case I was curious if the intent is to directly allow APIs from CF to pass transparently across to Foundation - if that is the case then we need to make certain we have a pattern more similar to NSCFString and such to do toll free bridging. What you have here is a "has-a" pattern bridge, I was wanting to make certain you were not intending for it to be a "is-a" pattern bridge.

tl;dr To hand out a CFWriteStream and allow use as a NSStream it needs to be the "is-a" pattern.

@parkera
Copy link
Contributor

parkera commented Nov 29, 2016

I'm going to go ahead and close this for now. Please re-open when changes requested are made. Thanks.

@parkera parkera closed this Nov 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants