Ios 是否应在Swift类前面加前缀，以避免潜在的Objective-C兼容性冲突问题

为了提供交叉兼容性，Swift允许生成桥接头，以便Objective-C可以与Swift类通信

由于Swift的奇妙的名称空间，我们不再需要担心为Swift文件加前缀，因为它们是由其包含的框架命名的。例如，

UIView

隐式名称空间为

UIKit.UIView

既然苹果正在推广框架，我想知道当存在两个具有相同符号的swift桥接头时，避免头冲突的最佳实践是什么

例如：假设我们有两个框架声明了一个名为

Downloader

的Swift类。

Downloader

提供界面：

downloadWithURL（url:NSURL）

---

生成桥接头将为这两个框架生成一个Downloader Swift.h文件。从而造成碰撞。避免这种情况的最佳做法是什么？

根据苹果公司的工程师的说法，

-Swift.h

标题使用了一个宏，该宏会将名称弄乱以避免冲突（请参阅WWDC视频，从45分钟40秒开始）。他们给出了一个

文档
Swift类的示例：

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

对于您的Swift代码，如果
MyApp
是该类所在的模块，则该类将作为
MyApp.Document
提供。因此，如果您有两个同名的Swift类来自不同的模块，例如，一个是您自己的，另一个来自开源Swift框架
SomeFramework
，它们将作为
MyApp.Document
和
SomeFramework.Document
提供给您的Swift代码

然而，在Obj-C方面，将这两个类导入到相同的词法范围会导致类“Document”的接口定义重复。
编译器错误。那只是Obj-C。。。不过，在绝大多数情况下，这不会成为问题，因为只要这两个类不侵犯对方的领土，您仍然可以在应用程序中导入它们。实际上，您希望在应用程序的同一模块中使用
MyApp.Document
和
SomeFramework.Document
的频率是多少？随着我们进入更快的时代，我不确定这个特定的问题是否需要一个特定的策略，与如此多的紧迫问题相比，例如，多核、分布式、功能性、触觉、预期性、可穿戴性、自主性等等