Zend 创始人提议创建PHP变种，暂命名为 P++

php P++| 2019-08-14

P++ 是临时代号，可能会更改。

今日消息，不久前从 Zend 公司离职的 Zeev Suraski 以 PHP 开发组成员的身份提议要创建 PHP 方言，暂命名为 P++。

图0：Zend 创始人提议创建PHP变种，暂命名为 P++

Zeev 表示，现有的 PHP 继续作为动态语言存在，而他提出的 PHP 方言暂命名为 P++，改成更严格的静态语言。他强调道，P++ 不是 PHP 的分叉。因为两者的代码库完全相同，维护代码库的开发者也会一样。另外，如果你安装了 PHP，那么将安装 P++，反之亦然。

总而言之，PHP 和 P++ 的绝大部分代码都是相同的。两者在特定差异点方面才会有不同的实现方式 —— 有点类似于 PHP 7 中的严格类型检查模式（strict_types），只不过 P++ 涉及的范围更广。

Zeev 还说到，动态语言和静态语言并无对错之分，这两种思想都是有价值的，然而创建一种同时迎合这两个人群的语言是一项挑战，这也是他提出 P++ 的原因之一。

所以 P++ 会有什么大胆的改进呢？据 Zeev 介绍，作为 PHP 的方言，P++ 会与 PHP 共存，但不会背负 PHP 语言背后的历史包袱。换句话说，这种新方言本质上可能会有更加严格的语法，它也会大胆移除被认为是负赘的元素，例如饱受诟病的短标签（short tags），并添加更复杂的功能 —— 尤其是那些非常适合强类型语言的特性，如此一来就无需为 PHP 引入相同的复杂性。

不过 Zeev 表示目前尚不清楚该如何标记一个文件为 P++ 文件，可能是在文件顶部的添加某种特殊的 header，例如：

<?p++?>
<?php 'Hello, world!'; ?>

此外，他们可能会找到将整个名称空间标记为 P++ 的方法，因此框架不必将每个单独的文件明确标记为 P++。

那作为开发者的我们，是否需要在 PHP 和 P++ 之间做出选择？前文已提到，由于 PHP 和 P++ 会同时安装，所以从这个层面来说，开发者不存在该选 PHP 还是 P++ 的犹豫。

P++ 的想法: 常见问题

这是一份对在 internals@^译注1 上提出的想法的常见问题澄清，它试图解决许多在随后讨论中被反复提出的问题。

注：P++ 是一个临时代码命名，未来可能会变化。

这到底是怎么回事？

试图将冗长的邮件内容浓缩为几点：

PHP 世界有两个大的阵营。第一个大致喜欢 PHP 的动态性，带有强烈的 BC^译注2 偏见，并特别强调简单性，另一个更喜欢减掉包袱，拥有更高级、更复杂功能的更严格的语言。
这里没有“对”或“错”。这两种流派都有效，并具有非常坚定的追随者。然而，创建一种同时迎合这两个阵营的语言则是一项挑战，这也是 internals@ 上争论的一贯的原因。
该提议是创建一种新的 PHP 方言（代码名 P++），与 PHP 并存，但不受语言背后的历史哲学约束。换句话说，这种新方言本质上可能更加严格，它可能会更加大胆地消除向后兼容，并删除被认为是“包袱”的元素（例如短标签），并添加更复杂的特性，尤其是那些非常适合严格类型化的语言的，而无需为 PHP 方言引入相同的复杂性。
这不是 PHP 代码分支。代码库将是同一个，在该代码库上工作的开发人员是相同的。绝大多数代码都是相同的。只有两种方言之间的特定差异点才会有不同的实现。它有点类似于 PHP 7 中的 strict_types 所做的，只是在更大的范围内。

我们真的要做的就是因为有些人不能放弃短标签吗？

这与短标签无关，“弃用短标签 RFC^译注3 ”不是这个想法的主要动力。这个提案的目标是更有野心，它是为 PHP 提供一个清晰的愿景，并希望通过向两个阵营提供他们想要的东西来最终解决两方的紧张关系。

为什么要分叉 PHP？

这不是分叉。代码库将完全相同，它将由相同的人开发版本。二进制文件将完全相同，如果你安装 PHP，你也将安装 P++，反之亦然。相同的二进制将运行 PHP，P++ 或组合 PHP/P++ 的应用程序。

虽然目前还不清楚如何将一个文件“标记”为 P++ 文件，但它可能是文件顶部的某种特殊标记，例如：

<?p++?>
<?php 'Hello, world!'; ?>

此外，我们可能会找到将整个命名空间标记为 P++ 的方法，因此，框架不必将每个单独的文件明确标记为 P++。

这意味着我们的开发工作量增加了一倍，而 internals@ 的贡献者已经很低（low）了。我们如何处理？

值得庆幸的是，这并不意味着是那样（工作量增加了一倍）。绝大多数代码将在 PHP 模式和 P++ 模式之间共享——包括源代码和运行时。

无论运行的文件是 PHP 还是 P++文件，数据结构、关键子系统、扩展、Web服务器接口、OPcache 以及其他所有代码都将是完全相同的代码。唯一的额外开发开销会是 PHP 和 P++ 之间的差异部分。

确实，这意味着我们必须维护某些代码片段的两个版本，并且我们在各个地方都会有一些 if() 语句，因为与 PHP 相比，P++ 可能会有额外的检查。但是，如果我们要转向更严格的 PHP 版本，这些元素无论如何都必须引入。此外，即使是严格阵营中的人，也不建议我们在没有提供迁移途径的情况下转向未来严格版本——实际上，这种方法所涉及的努力和几乎任何其他的方法都是相似的。

当我们转向更严格的 PHP 8/9时，为什么不只是开发一个永久维护的 PHP 7.4 长期维护版？

这种方法存在许多问题。即使我们忽视这样一个事实，即这会让庞大的动态偏好阵营悬而未决——没有任何特性或性能更新，从开发工作的角度来看，这是不切实际的。这与这个提议不同，事实上，这确实意味着事实上的分叉。

我需要在 PHP 和 P++ 之间做出选择吗？

是，也不是。如上所述，当你安装一个，你就有了另一个，所以就应用而言，你可以在一台服务器上运行这两种方言。然而，实际上，项目和个人通常可能选择并标准化其中一个，类似于严格类型的情况。

我能在同一个应用程序中混合使用 PHP 和 P++ 吗？

是的。虽然我们需要确定精确的机制，但代码是 PHP 还是 P++ 的指定将在文件级别，而不是在请求级别。单个执行（请求）可以加载许多不同的文件，这些文件可以来自两种方言。PHP文件中的代码将表现为 PHP 语义——而来自 P++ 文件的代码将表现为 P++ 语义。这也是，与 strict_types 类似。

虽然这开始听起来可能听很尴尬，但可能会有非常实用的用例。例如，PHP 应用程序使用的只含 P++ 的框架，反之亦然。对于那些熟悉 C 和 C++ 的人来说，这有点类似。

这是否意味着 PHP 将不再发展？所有新功能都会用于 P++ 吗？

不，这只是意味着它会以不同的方式发展。严格性和类型相关的功能可能只适用于 P++，并且只能在 P++ 文件中使用。向后兼容偏差将保留在 PHP 中（这并不意味着向后兼容永不会被打破，只是每个这样的案例必须有良好的投资回报案例）。

但是，与此无关的功能，例如引擎的性能改进（如 JIT ），扩展的开发，或新的异步相关的功能，PHP 和 P++ 都可以使用。

这个方法有什么好处？

这种方法有很多好处。首先，它为 internals@ 的两个阵营提供了一个很好的解决方案。那些喜欢 PHP 动态特性的人可以保留它，而那些喜欢更严格类型语言的人也可以获得它，而不受任何 PHP 限制。而替代方案是零和游戏，一个阵营的胜利是另一个的失败，反之亦然。

除了设计一个好的技术解决方案（使我们能够以最少的努力支持整个受众）之外，还可以终结近年来 internals@ 上争论的关键根源。

最后，虽然本文档的大多数读者可能是技术人员，但应该注意的是，启动 P++ 将从一个新的基点^译注4不计过去重新开始，可能具有巨大的定位和品牌优势。未使用 PHP 的公司、开发经理和个人开发者更有可能注意到 P++ 的推出，而不是 PHP 8.0 或 PHP 9.0 的推出。

我们不是冒着分裂用户群的风险吗？

在某种程度上，我们是。但这不是这一想法的缺陷，而是现实已经存在的表现。

如上所述，那里有很多人喜欢 PHP 的动态本质，并且谨慎地看待尝试使其越来越多地面向类型。

与此同时，还有另外一群看着 PHP 的人，自己在想：“为什么它变得如此缓慢，以至于我最终要放弃这动态的废材（原文：dynamic nonsense）？”

这里没有对或错。这两种观点都有效。当我们研究在这两个相互矛盾的观点之间架起桥梁的可能的解决方案时，没有太多可用的方案：

坚持使用动态PHP。这将不会被更严格语言的支持者所接受。
向严格的PHP发展。动态语言的支持者不会接受这一点。
分叉代码库。无论如何完成，都是所有参与者的净损失选项。这样做没有技术优势，即使我们想要（我们不想要），我们也没有足够的贡献者去做。
提出一些创意解决方案，以满足双方观众的需求。这就是该提案试图做的。它在保持项目本身统一的同时，也确保两种方言之间的永久互操作性。这虽然会有一定程度的碎片化，但它仍然是满足每个人的主要需求的最小可能。

这与 Nikita^译注5 版本的想法有何不同？

这两个想法之间有许多相似之处，但也存在一些实质性差异。请注意，这是基于对版本方法的有限理解，因此部分可能缺乏，不准确或不正确。

在这个提议中，有一个明确的目标是保持当前动态类型的 PHP，作为一个长期的，完全支持的，平等的对等方言。发版本的方法将当前行为视为“遗留”。这意味着它可能会被劝止（使用），然后在某些时候弃用和删除。
推出策略完全不同。 P++ 提案旨在首先关注兼容性破坏元素，例如严格的操作、类型转换逻辑的更改、数组索引处理、需要变量声明等等，并且旨在在 P++ 的第一期提供它们。这样做的目的是允许新项目/框架重新开始，而不需知道在引入更多兼容性更改时，他们可能不得不在一两年内进行重大改写。版本化提案似乎没有这样的目标，而是旨在逐步添加/更改 PHP 中的元素。
与推出方式相关，版本化方法不允许只有两种方言，而是任何数量的方言。我们可能有 PHP2020 方言，以及 PHP2022 方言和 PHP2027 方言。如果我们全部保留它们，实际上这可能会增加我们的维护复杂性。
该提议还提到了 PHP 与 P++（保守与积极）的不同打破向后兼容策略，而版本化方案可能根本不会涉及该主题。
版本提案与此提案的定位/营销方面并不完全相同。

重要的是，要注意这两个想法不一定是相互排斥的。我们可以介绍 P++ 并使用版本进行改进，特别是当证明很难将所有重要的变化都放到 P++ 的第一期中。

有哪些挑战？

在我们能运行第一个 P++ 应用程序之前，不乏挑战。

我们需要获得支持。这意味着，两派的人都需要放弃让 PHP 完全动态或完全类型化的梦想，而忽略那些与他们想法不同的人。这似乎是一个非常重大的挑战。
为获得成功，P++ 第一个版本应该处理来自 PHP 的所有，或至少大多数兼容性破坏的更改，以便切换（可能相当痛苦）的开发人员不必在未来重新审核/彻底重构他们的代码。一些人表示担心，由于我们的开发人员能力有限，他们可能过于乐观，无法在一期发布。一旦我们对列表的内容有了更好的了解，我们就必须对此进行评估。请注意，这并不意味着我们需要在第一个期中实现我们可能对 P++ 提出的所有想法，只是我们应该优先考虑会触发大量最终用户代码重写的元素，并尝试在我们的第一版之前处理它们。
当然,最具挑战性的——我们需要为这种新方言找到一个合理的名字。

pplusplus/faq.txt · 最后修改： zeev 于 2019/08/09 21:44

译注

internals@：PHP 内部开发人员邮件列表。这里涉及 PHP 的开发机制，当内部讨论成熟后，会公开在 externals，通常用来提交 RFC 和发布版本通知。
BC：即 Backward Compatibility，向后兼容，也叫向下兼容，兼容过去的版本，即升级的软件要考虑旧版本的兼容性，比如，Office 2019 的 Word 默认使用 .docx 文件格式，但也可以打开 Office 2017/2013/2010，甚至是 2003 的 .doc 格式。相对的概念叫做 FC，即 Forward Compatibility，向前兼容，也叫向上兼容，即升级的软件会考虑对未来的兼容性。这在软件中通常为一个确定的接口和约定，未来依然遵循，即可实现向前兼容。
RFC：即 Request for Comments，语言特性的加入，以及标准化变更管理的方法，通常加入新特性时，会为新特性提交 RFC 并给出例子，变更委员会评估通过后，语言会合入实现的源码，并入新版本。
新的基点：a clean slate，美国习语，即不计过去新的开始。
Nikita：一位 internals@ 上的发言者，提议在版本中加入特性。顺便提一句，美剧《Nikita》值得一看。

（本文翻译为笔者原创，限于水平有限，如翻译中有不妥的地方请回复留言，如转载请注明出处：IT桃花岛）

Zend 创始人提议创建PHP变种，暂命名为 P++