PHP: P++ 官方说明文档

• Date: 2019-08-09
• Author: Zeev Suraski, zeev@php.net

这是对 internals@ 提出的想法进行阐释的 FAQ。对讨论中反复提到的问题进行解答。

注意: P++ 是临时名称，可能会更改。

关于这个项目

将长文邮件浓缩成几点：

• 目前，关于 PHP 有两个大的思想流派。第一个是认为 PHP 应该是简单的，带有强烈 BC 偏见和强调简单性的语言，而另一种，更加喜欢 PHP 是一门静态的语言，减少包袱和更多高级/复杂的功能。

• 这并没有对错之分。两种流派都是有效的，并且具有非常多追随者。然而，创建一种迎合这两大人群的语言是一项挑战。这也是internals@（内部） 讨论至今的原因。

• 这个提案是创建一门新的 PHP（项目名叫 P++），与 PHP 并肩存在，但是不受语言背后的历史哲学所约束。换句话说，这门语言（P++）可能更加的严格，它可能会大胆地移除 BC 和删除一些认为是 “包袱” （例如短标签），并且添加更多复杂的功能 - 尤其是更加符合一门静态类型语言 - 无需为 PHP 引入相同的复杂性。

• 这并不是 fork 。代码库将是相同的，处理该代码库的开发人员将是相同的。 绝大多数代码都是相同的。 只有两种语言之间的特定差异点才会有不同的实现方式。 它有点类似于PHP 7中的 strict_types - 只是在更大的范围内。

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

这与短标签无关，而短标签取消 RFC 并非主要动机。 这项提议的目标更加远大——他为 PHP 提供了一个清晰的远景——希望最终能平定两派之间内部的思想斗争——为两派都提供他们想要的。

为什么要 fork PHP？

这并不是一个 fork。代码库将是相同的，它也将由同一批人开发与发行。二进制文件也是相同的——如果你安装 PHP ，那么将同时安装 P++，相反也是如此。相同的二进制文件将运行 PHP ，P++ ，或者 PHP/P++ 组合应用。

虽然目前还不清楚如何将一个文件标记为 P++ 文件，可能是文件顶部某种特定的头：

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

此外，我们还能找到将整个命名空间标记为 P++ 的方法，这样框架就不需要单独将每个文件标记为 P++ 了。

这意味着我们的开发工作量增加了一倍，而内部的开发人员贡献已经很低了。 我们将如何处理？

值得庆幸的是，这并不存在。 绝大多数代码将在 PHP 模式和 P ++ 模式之间共享 - 包括源代码和运行时代码。

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

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

为什么不发布一个永久的 PHP 7.4 LTS 就可以了，反正我们将迎来更严格的 PHP 8/9？

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

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

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

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

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

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

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

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

但是 - 不相关的功能 - 例如引擎中的性能改进 例如 JIT 开发 扩展或新的异步相关功能 - 将适用于 PHP 和 P ++。

这种方案有什么好处？

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

除了成为一个好的技术解决方案 - 这使我们能够以最少的努力支持我们的整个观众 - 这也可以结束近年来内部人员@的主要争论来源。

最后 - 虽然本文档的大多数读者都可能是技术人员 - 但应该注意的是，推出 P ++，从一个干净的平板开始 - 可能具有实质性的定位/品牌优势。 排除 PHP 的公司，开发经理和个人开发人员更有可能注意到 P ++ 的推出，而不是推出 PHP 8.0或 PHP 9.0。

我们是不是冒着破坏用户群的风险?

在某种程度上，我们确实在这样做。但是这并不是设计的缺陷，而是在现实中已然存在的一种表现。

正如上面说阐述的，有很多人喜欢 PHP 的动态特性，并且谨慎地看待，越来越多尝试将它变成面向其他类型的实现。

与此同时，还有另一伙人看着 PHP，他们也在想：“为什么它会变得这么缓慢？以至于发出摆脱这种动态特性的豪言壮语。”

这并没有对错。 两种观点都是正确且有效的。当我们研究在这两个相互矛盾的观点之间，连接着潜在的解决方案时，其实并没有太多可用的解决方案：

1. 坚持动态 PHP. 静态语言的支持者不会接受这一点。

2. 想静态 PHP 演变. 动态言语支持者也同样不会接受这一点

3. Fork 代码. 无论怎样，这对于每个人来说，都是一个比较纯粹的选项，这样做是没有技术优势的（即使我们想这样做），但是我们也没有足够多的贡献者。

4. 提出一些创意解决方案，以迎合两个观众. 这就是本提案试图做得事情。它既保持项目本身的统一，又确保两种特性（动态和静态）之间永久的相互操作性 - 这样虽然会有一定程度的碎片化，但它仍然是最小的可能仍然满足每个人的主要需求。

这与 Nikita 版本的想法有何不同？

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

1.在这个提案中 - 有一个明确的目标是保持当前的，动态类型的PHP - 作为一个长期的，完全支持的，平等的方言。 版本方法将当前行为视为“遗留”。 这意味着它可能会气馁，然后，在某些时候，弃用和删除。

2.推出策略完全不同。 P ++提案旨在首先关注兼容性破坏元素 - 例如严格操作，类型转换逻辑的更改，数组索引处理，需要变量声明等等 - 并且旨在在P ++的第一部分提供它们。 这样做的目的是允许新项目/框架重新开始，而不知道在引入更多兼容性更改时，他们可能不得不在一两年内进行重大改写。 版本提案似乎没有这样的目标 - 而是旨在逐步添加/更改PHP中的元素。

3.与推出相关 - 版本方法不允许只有两种方言 - 但任何数量的方言。 我们可以使用 PHP2020 方言，以及 PHP2022 方言和 PHP2027 方言。 如果我们全部保留它们 - 这实际上可能会增加我们的维护复杂性

4.该提案还提到了 PHP 与 P ++（保守与积极）的不同 BC-break 策略，而版本可能根本不会涉及该主题。

5.版本提案与此提案的定位/营销方面并不完全相同。

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

这样会有哪些挑战？

在我们运行第一个 P ++ 应用程序之前，将面临很多挑战。

我们需要得到认同。 这意味着来自两种学派的人们都需要放弃让 PHP 完全动态或完全类型的梦想，同时忽视那些与他们不同的人。 这似乎是一个非常重大的挑战。

2.为了获得成功，P ++ 的第一个版本应该处理所有或至少大多数来自 PHP 的兼容性破坏性更改 - 以便制作（可能相当痛苦）切换的开发人员不必重新审核/从根本上 将来再次重构他们的代码。 有些人表示担心他们可能过于乐观，不能用我们拥有的有限的开发者权力进行一次决定。 一旦我们对列表的内容有了更好的了解，我们就必须对此进行评估。 请注意，这并不意味着我们需要在第一个版本中实现我们可能对 P ++ 提出的所有想法 - 只是我们应该优先考虑会触发大量最终用户代码重写的元素 - 并尝试在我们的第一个版本之前处理它们。

3.当然，最具挑战性的是 - 我们需要为这种新方言找到一个合理的名称。

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

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://wiki.php.net/pplusplus/faq

译文地址：https://learnku.com/php/t/32413