I would suggest that the way to do it is to follow the NSString/NSNumber
approach used in swift-corelibs-foundation where the structural size is
equivalent.
the layout would roughly look like:
open class InputStream : Stream {
typealias CFType = CFReadStream
// This layout MUST be the same as CFReadStream so that they are bridgeable
private var _base = _CFInfo(typeID: CFReadStreamGetTypeID())
private var _flags: CFOptionFlags = 0
private var _error: UnsafeMutableRawPointer? = nil
private var _info: UnsafeMutableRawPointer? = nil
private var _callBacks: UnsafeMutableRawPointer? = nil
#if os(OSX) || os(iOS)
private var _lock = pthread_mutex_t()
#elseif os(Linux)
private var _lock = Int32(0)
#endif
private var _previousRunloopsAndModes: UnsafeMutableRawPointer? = nil
#if DEPLOYMENT_ENABLE_LIBDISPATCH
private var _queue: UnsafeMutableRawPointer? = nil
#endif
internal var _cfObject: CFType {
return unsafeBitCast(self, to: CFType.self)
}
...
}
This would ensure the memory size of the allocation of InputStream would be the
same as CFReadStream.
These two calls would then need to be un-commented in NSSwiftRuntime.swift
// _CFRuntimeBridgeTypeToClass(CFReadStreamGetTypeID(),
unsafeBitCast(InputStream.self, UnsafeRawPointer.self))
// _CFRuntimeBridgeTypeToClass(CFWriteStreamGetTypeID(),
unsafeBitCast(OutputStream.self, UnsafeRawPointer.self))
and __CFSwiftBridge would need entries for calling out to swift for subclassers.
> On Sep 21, 2016, at 1:03 PM, Bouke Haarsma via swift-users
> <swift-users@swift.org> wrote:
>
> The one that comes with SwiftFoundation
> (https://github.com/apple/swift-corelibs-foundation/tree/master/CoreFoundation
>
> <https://github.com/apple/swift-corelibs-foundation/tree/master/CoreFoundation>).
>
> I think it should be a bug that CFReadStream cannot be bridged to
> (NS)InputStream, as otherwise there’s no way to intertwine Sockets
> (CFSockets) with SwiftFoundation. As the implementation already uses a
> CFReadStream internally
> (https://github.com/apple/swift-corelibs-foundation/blob/d3872cb094124d5dd189839505ae73e2fa717cfd/Foundation/NSStream.swift#L122
>
> <https://github.com/apple/swift-corelibs-foundation/blob/d3872cb094124d5dd189839505ae73e2fa717cfd/Foundation/NSStream.swift#L122>),
> it would be a matter of adding an initializer. However the value is private,
> so adding the initializer cannot be done from an extension.
>
> —
> Bouke
>
>> On 21 Sep 2016, at 21:22, Jens Alfke <j...@mooseyard.com
>> <mailto:j...@mooseyard.com>> wrote:
>>
>>
>>> On Sep 20, 2016, at 9:38 PM, Bouke Haarsma via swift-users
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>
>>> When working with CoreFoundation objects (e.g. CFReadStream, CFWriteStream)
>>> it isn't immediately obvious to me how to bridge them to SwiftFoundation
>>> counterparts (InputStream / OutputStream).
>>>
>>> The following works on OSX, but doesn't work on Linux;
>>
>> What implementation of CF are you using on Linux? OpenStep?
>>
>> The bridging between Swift and Obj-C Foundation classes is only implemented
>> on Apple platforms. It’s not part of the open source release. The plan is to
>> implement classes like InputStream in native Swift as part of the standard
>> library; that work is in progress.
>>
>> —Jens
>
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
