If the Swift class needs to be prefixed to avoid potential Objective-C problems

Question

To provide cross-compatibility, Swift allows you to create a bridge header so that Objective-C can interact with Swift classes.

Due to Swift’s wonderful namespace, we no longer need to worry about the prefixes of our Swift files, as they are placed in the space containing their framework. A UIView , for example, implicitly denotes namespaces as UIKit.UIView .

Now that Apple is pushing the frameworks, I was wondering what is the best way to avoid header conflicts when there are two quick headers with the same characters.

Example. Let's say we have two structures that declared a Swift class called Downloader . Downloader provides an interface: downloadWithURL(url: NSURL)

Generating the bridge header will create the Downloader-Swift.h file for both of these frameworks. Thus, a collision occurs. What are the best methods to avoid this?

Answer 1

According to Apple engineers, the header <#Module Name#>-Swift.h uses a macro that manages the name to avoid conflicts (see WWDC Swift Interoperability In Depth video starting at 45 min, 40 s). They gave an example of the Document Swift class:

 SWIFT_CLASS("_TtC5MyApp10Document") @interface Document : UIDocument // rest of the interface... 

In your Swift code, the class will be available as MyApp.Document if MyApp is the module it is in. So, if you have two Swift classes with the same names from different modules - say, one of them is your own and the other is from the open Swift SomeFramework structure - they will be available for your Swift code as MyApp.Document and SomeFramework.Document ...

However, on the Obj-C side, importing these two classes into the same lexical area results in a Duplicate interface definition for class 'Document' compiler error. It's just Obj-C ... In the vast majority of cases, this will not be a problem, since you can import these two classes into the application if they do not violate each other. Indeed, how often do you want to use MyApp.Document and SomeFramework.Document in the same module of your application? As we move forward in a shorter time, I’m not sure that this particular issue requires a certain strategy compared to pressing issues such as multicore, distributed, functional, tactile, anticipating, portable, autonomous, etc. ..