。在处理一个大型开源项目时，我们遇到了这个问题，因此这是一个很好的案例研究/示例:
我们当前的解决方法:
在 iOS8 中，Apple 再次做到了这一点，并添加了更多解决此问题的类，包括“评论”。 (Apple？真的吗？哦，来吧，伙计们!在向全局空间发送垃圾邮件之前请三思!)。这越来越难以解决。
常规解决方案:由于 C/ObjC 没有命名空间(呜呜!)，我们会为每个类添加前缀。 SVG 规范有一个官方前缀——“SVG”——我们使用它。对于非规范类，我们有一个较长的前缀，这可能是我们的开源项目独有的。
但是对于 DOM，我们包含了我们自己的 DOM 实现，并且开发人员的项目可能有不同的专有 DOM 实现。在这里很难想出合理的前缀。 Apple 已经在 Obj-C 平台上保留了“DOM”作为前缀。
如果我们使用前缀“SVGKitDOM”，这将是最小的正确前缀名称，这会使 DOM 中类名的长度增加三倍(!)，并且通常会使代码不可读。这也违反了 Apple 对 2-3 个字母前缀的偏好。
该项目是开源的，因此从技术上讲:任何人都可以将源代码全局重命名为他们想要的任何内容。但这对人们来说是一个巨大的痛苦。
我一直在考虑巧妙的宏化解决方法 - 例如#define OPTIONAL_PREFIX DOM/OPTIONAL_PREFIX SVGKitDOM/..etc 允许用户使用他们需要的任何前缀快速重建整个 DOM 和依赖的 SVG 库。
...但这似乎仍然容易出错和困惑。而且它会使新的提交成为噩梦:我们必须教育每个提交者如何在每个类名中使用宏(如果这甚至适用于 ObjC)。
啊!
一定有更简单的方法吗？ 30 多年来，命名空间冲突一直是个问题。
注意:这是 Objective-C，所以它是 C 的超集，但链接过程不是超集 - 例如，Apple 禁止所有人进行动态链接。所以，我们需要一个静态的解决方案
。
或许，你可以使用不常提及的@compatability_alias属性，如下:
文件
refixedHeader.h
@interface my_longly_prefixed_ClassThatDoesSomething : NSObject
@end
文件:ConvenienceHeader.h
@compatibility_alias ClassThatDoesSomething my_longly_prefixed_ClassThatDoesSomething
如果用户有他们自己的专有 DOM 实现，那么让他们不要导入便利 header ，否则就这样做。
这行得通吗？
关于ios - 如何使 Obj-C 库全局可重命名(每个类/导出的符号)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26929576/
| 欢迎光临 OGeek|极客世界-中国程序员成长平台 (http://ogeek.cn/) | Powered by Discuz! X3.4 |