如何防止 PHP 命名空间冲突（预捆绑包）答案

【问题标题】：How to prevent PHP namespace conflicts (pre-bundled packages)如何防止 PHP 命名空间冲突（预捆绑包）
【发布时间】：2016-09-18 09:58:27
【问题描述】：

假设我们有一个 PHP 项目，其依赖项 A 和 B 分别依赖于 PHP 库 X，但版本不同。

通常，人们会使用 PHP 依赖管理器，例如 composer，它可以通过在兼容 A 和 B 的版本中包含 X 来解决此冲突 或在无法解决冲突时显示错误。

现在，许多 PHP 应用程序允许其用户安装插件，只需上传预先捆绑的包并将它们解压缩到特定的插件目录即可。

如果 A 和 B 是这样的预捆绑插件，并且两者都带有自己的库版本 X，我们可能会遇到问题因为没有依赖管理器可以为我们选择兼容的 X 或在没有时显示错误。

为了防止由于 PHP 无法将不同版本的库 X 两次加载到同一个命名空间中而导致的任何此类冲突，我们可以将 A 的 X 和 B 的 X 进入不同的命名空间（这可能很难自动完成，因为我们需要一个 PHP 解析器...） .

我的问题是：

您将如何解决这个问题？您能推荐这种方法还是有更好的解决方案？

【问题讨论】：

标签： php namespaces composer-php version conflict

【解决方案1】：

不更改代码就没有解决方案。如果文件系统中确实存在“\Vendor\AnyClass”的两个版本，并且执行代码以同时使用它们，则会出现错误，因为不允许重新声明该类，或者因为预期的类不兼容。它只有在类的接口实现相同的情况下才有效，即两个代码兼容。如果不只是一个类，而是一整棵对象树，即使它们提供了兼容的接口，也可能对混合来自不同版本的类做出不良反应，那么兼容性问题就会变得复杂。

改变命名空间就是改变代码。谁对此负责？我可以想到一些自动代码解析器，它能够为每个插件添加一个特定的命名空间前缀，但据我所知，该任务还没有在 PHP 中完成。我公司的 Java 人说，那里已经解决了这样的问题，但我没有详细信息。

此外，它会使您的代码库翻倍，并且重复的代码必须只共享您拥有的一个操作码缓存。

我知道 Wordpress 的核心开发人员仍在努力解决这个问题。有一些关于如何使用 Composer 进行依赖管理的编码建议（即插件及其依赖项），但我认为他们目前还没有取得足够的进展。

基本上你有两个选择： 1. 创建一个代码命名空间前缀，解析属于插件的所有文件（因此插件作者必须以某种方式包含他的依赖项），更改代码，忍受代码重复，然后查看在调试方面等待您的是什么。缺点是该插件之外的任何代码都不能轻松地直接使用插件代码，因为这意味着知道创建的前缀。 2. 实现某种形式的依赖管理，最好使用 Composer，并且不要更改命名空间。

更新：我再次咨询了我的 Java 同事，他们对 Java 的声明基本上与我对 PHP 的声明相同：同一个类名下不能有两个不同版本的类, 甚至对于 Java 也没有“魔法”，只是将类重命名为不同的命名空间。

【讨论】：

感谢您的意见！您基本上是在确认我的想法 - 除了更改依赖项的名称空间之外别无选择。 “实施某种形式的部门管理”是什么意思？正如我的问题所述，composer 不是选项，因为插件在上传到服务器后必须“开箱即用”。
通过说“实施某种形式的部门管理”，我建议您的插件上传可以像 Composer 一样声明它们的依赖关系，您至少可以尝试检测任何冲突并解决问题。然而，实现 Composer 已经做的同样的事情是很疯狂的，所以使用 Composer 组件来帮助你完成这项任务可能是明智的。您还可以强制任何插件仅使用一个命名空间，通过检查所有文件来强制执行它。问题解决了。无论如何，任何插件都必须包含依赖项，它们不能依赖任何东西。
prefix 实际上有几种替代方法，可以更改 PHP 文件的范围（命名空间）并自动更新 Composer 依赖项和您的代码库。有关更多信息，请查看此答案：3rd party dependency conflict in developing Wordpress Plugin
@AnibalSanchez 有趣的是，您提供的链接中的答案都在谈论为 PHP 代码添加前缀。您指的是哪些替代方案？
@sven 我认为我使用的英文表达不正确或令人困惑......我的意思是“有几种可用的工具可用于更新 Composer 依赖项和您的代码库。 ..”