最新消息:XAMPP默认安装之后是很不安全的,我们只需要点击左方菜单的 "安全"选项,按照向导操作即可完成安全设置。

PHP新分支:P++,你还敢说php是弱类型语言吗?

XAMPP相关 中文小张 12浏览 0评论

摘要:PHP 语言的创始人 Rasmus Lerdorf 生于 1968 年,今年已 51 岁,他在 1995 年以 Personal Home Page Tools 为名发布了 PHP 1.0。他的辉煌随着雅虎在搜索领域的颓败而黯淡。

1997 年,以色列程序员 Zeev Suraski 及 Andi Gutmans 加入了 Zend 公司 的 PHP 语言开发,发布了 PHP 3, PHP 4, PHP 5,注意没有 PHP 6,再到现在的 PHP 7。

1975 年出生的 Zeev Suraski 在 Zend 工作了 20 年。也许是在语言、架构和库的工作上找不到发展方向了。

前几天 Zeev Suraski 宣布从 Zend 离职,业界比较惊讶,PHP 7 优化的开发者鸟哥说是这是早已预定好的事。

原来 Zeev Suraski 辞职,他想做 P++,那 P++ 是啥?他通过《P++ idea: FAQ》进行了回答,笔者作了全文翻译。

这是一份对在 internals@(internals@:PHP 内部开发人员邮件列表。这里涉及 PHP 的开发机制,当内部讨论成熟后,会公开在 externals,通常用来提交 RFC 和发布版本通知。) 上提出的想法的常见问题澄清,它试图解决许多在随后讨论中被反复提出的问题。

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

这到底是怎么回事?

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

1. PHP 世界有两个大的阵营。
第一个大致喜欢 PHP 的动态性,带有强烈的 BC偏见(BC:即 Backward Compatibility,向后兼容,也叫向下兼容,兼容过去的版本,即升级的软件要考虑旧版本的兼容性,比如,Office 2019 的 Word 默认使用 .docx 文件格式,但也可以打开 Office 2017/2013/2010,甚至是 2003 的 .doc 格式。

相对的概念叫做 FC,即 Forward Compatibility,向前兼容,也叫向上兼容,即升级的软件会考虑对未来的兼容性。

这在软件中通常为一个确定的接口和约定,未来依然遵循,即可实现向前兼容。),并特别强调简单性,另一个更喜欢减掉包袱,拥有更高级、更复杂功能的更严格的语言。

2. 这里没有“对”或“错”。
这两种流派都有效,并具有非常坚定的追随者。然而,创建一种同时迎合这两个阵营的语言则是一项挑战,这也是 internals@ 上争论的一贯的原因。

3. 该提议是创建一种新的 PHP 方言(代码名 P++),与 PHP 并存,但不受语言背后的历史哲学约束。

换句话说,这种新方言本质上可能更加严格,它可能会更加大胆地消除向后兼容,并删除被认为是“包袱”的元素(例如短标签),并添加更复杂的特性,尤其是那些非常适合严格类型化的语言的,而无需为 PHP 方言引入相同的复杂性。

4. 这不是 PHP 代码分支。

代码库将是同一个,在该代码库上工作的开发人员是相同的。绝大多数代码都是相同的。只有两种方言之间的特定差异点才会有不同的实现。它有点类似于 PHP 7 中的 strict_types 所做的,只是在更大的范围内。

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

这与短标签无关,“弃用短标签 RFC(RFC:即 Request for Comments,语言特性的加入,以及标准化变更管理的方法,通常加入新特性时,会为新特性提交 RFC 并给出例子,变更委员会评估通过后,语言会合入实现的源码,并入新版本。)”不是这个想法的主要动力。

这个提案的目标是更有野心,它是为 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 的推出。

转载请注明:XAMPP中文组官网 » PHP新分支:P++,你还敢说php是弱类型语言吗?