Swift类应该加上前缀以避免潜在的Objective-C兼容性冲突问题
为了提供交叉兼容性，Swift允许生成桥接头，以便Objective-C可以与Swift类进行通信。
由于Swift的奇妙命名空间，我们不再需要担心我们的Swift文件前缀，因为它们是由包含框架命名的。 例如， UIView是隐式名称空间为UIKit.UIView 。
既然Apple正在推动框架，我想知道当存在两个具有相同符号的快速桥接头时，避免头部冲突的最佳实践是什么。
一个例子：假设我们有两个框架声明了一个名为Downloader的Swift类。 Downloader提供界面： downloadWithURL(url: NSURL)
生成桥接头将产生这两个框架的Downloader-Swift.h文件。 从而引起碰撞。 避免这种情况的最佳做法是什么？
根据Apple工程师的说法， <#Module Name#>-Swift.h标头使用一个宏来破坏名称以避免冲突（参见WWDCvideoSwift互操作性深度 ，从45分钟开始，40秒）。 他们举了一个Document Swift类的例子：
SWIFT_CLASS("_TtC5MyApp10Document") @interface Document : UIDocument // rest of the interface...
对于你的Swift代码，该类将作为MyApp.Document ，如果MyApp是它所在的模块。那么，如果你有两个同名的Swift类来自不同的模块 – 比如，一个是你自己的，另一个是你自己的来自开源Swift框架SomeFramework – 它们将作为MyApp.Document和SomeFramework.Document提供给你的Swift代码……
但是，在Obj-C方面，将这两个类导入相同的词法范围会导致Duplicate interface definition for class 'Document'编译器错误的Duplicate interface definition for class 'Document' 。 那只是Obj-C ……但是在绝大多数情况下，这不会是一个问题，因为你仍然可以在应用程序中导入这两个类，只要它们不会侵入彼此的领域。 实际上，您希望在应用程序的同一模块中使用MyApp.Document和SomeFramework.Document如何？ 随着我们进入更快的时代，我不确定这个特定的问题需要一个特定的策略，与许多紧急问题相比，例如，多核，分布式，function性，触觉，预期，可穿戴，自治等……