[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift
Marco Masser
lists at duckcode.com
Sat Feb 13 05:44:58 CST 2016
> On 2016-02-12, at 20:58, Tony Parker <anthony.parker at apple.com> wrote:
>
>>
>> On Feb 12, 2016, at 1:28 AM, Marco Masser via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> […]
>>
>> • On the plus side: Converting Objective-C classes into protocols along with a conforming struct would make something like inheritance possible again via protocol conformance.
>> For example, if the NSCountedSet Objective-C class became a CountedSet Swift protocol along with a CountedSetImpl (or whatever) Swift struct that conforms to it, you could write your own type that conforms to the CountedSet protocol and use that with every existing Objective-C code that expects an NSCountedSet. That sounds super awesome!
>
> Close… but every Objective-C method that takes an NSCountedSet assumes that that NSCountedSet is a subclass of NSObject.
Right, that’s a problem. It could work if the CountedSet protocol requires having an NSCountedSet property:
protocol CountedSet {
var storage: NSCountedSet { get }
// All of NSCountedSet and its superclasses' methods
...
}
… and bridging between the CountedSet Swift protocol’s storage and NSCountedSet parameters to Objective-C methods worked automatically. But I don’t like this approach because the nice abstraction of the CountedSet protocol is useless when it is tied to the Objective-C class anyways.
> There are some other complexities to this approach as well: how do we deal with types that are pointers-to-pointers in Objective-C? (API that takes NSCountedSet **, e.g.). What about types where frameworks layer on functionality via categories?
Yet another problem with this approach…
> I have some ideas on this topic but I’m still working on it.
I’d love to hear those ideas when you’re ready to share them!
Taking a step back, I think all these problems seem like they have already been solved in Swift’s Array, String, Dictionary, and Set structs in that they bridge to their Foundation Objective-C counterparts seamlessly and they make categories to the Objective-C classes available on the Swift structs. I haven’t looked at the source, but I assume all of these bridges are special cases and require a lot of code to work. If that mechanism could be made to work for arbitrary class types, I think the problem would be solved, wouldn’t it?
Cheers,
Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160213/b472dfd3/attachment.html>
More information about the swift-evolution
mailing list