[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?


-------------- 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