解读 P++提案: P++ vs PHP 孰强孰弱, P++会成为PHP的里程碑吗?

 

P++是php语言的一个变种,它具有更高级的功能和更少的历史包袱。

P++是由Zeev Suraski 在PHP社区中提出来的,他目前与php共存,但是它抛弃了php的历史遗留问题,所以更加地简洁,更加地优雅。P++不会是一个分支,它本质上会更严格,并且可能会更加大胆,具有向后兼容性。

我们都知道php是弱类型语言,这个给我们带来很大的好处,我们可以非常灵活地去操作一个变量,在php中,数组和对象转换也是非常地容易。然而,弱类型也带来了很多问题,比如我们经常对一个变量的类型错误使用,导致许多BUG的出现。然而P++坚持了严格类型,它使得PHP无论在性能和架构上都提升巨大。

与PHP本身一样,P++主要用于服务器端Web开发。计划中的PHP8版本预计将PHP扩展到Web开发之外,具有即时引擎和与C / C ++库的互操作性。

PHP和P++中的绝大多数代码都是相同的。大多数代码将在源代码和运行时在PHP和P++节点之间共享。但他们会有不同的实现。二进制文件将完全相同。

无论文件是作为PHP还是P++执行,数据结构,Web服务器接口,关键子系统以及其他大多数都将是完全相同的代码。但是,必须维护某些代码片段的两个版本。与PHP相比,P++可能会有额外的检查。开发人员可以在同一个应用程序中混合搭配PHP和P++。两种方言都可以在一台服务器上运行。

如果P++可以得到大幅推广,那将意味着PHP将会向不同方向演变。严格和类型相关的功能可能会在P++中出现。向后兼容的偏差将保留在PHP中。P++和PHP都可以提供不相关的功能,例如引擎的性能改进或扩展的开发。

P++语言发展方向:

  • 坚持使用动态PHP,不过这对于严格类型语言的发展是不利的。
  • 向更严格的PHP发展,那么将抛弃动态语言之前的优势。
  • 设计一个迎合两个受众的解决方案,这是P++提案的尝试。

P++语言发展中遇到的困难:

  • 将PHP代码转换为P++并不是一件容易的事。
  • PHP工具不支持P++。无法轻易实现P++。
  • P++的出现将打破PHP兼容性。

 

总之,目前P++只是理论性地提出,距离它真正的发展还有很长的路要走,而我们现在更加关心的是PHP8的发展方向。

 

解读 PHP 的 P++提案

周末看到一篇文章说 PHP 创始人提议将 PHP 拉出新分支,创建 P++ 语言。随后阅读了一下 Zeev Suraski 发起的这个邮件列表,大致了解了一下,这里做个解读。

Zeev Suraski 就是几周前爆出的 PHP 核心开发者从 Zend 公司离职消息里面的主角。Zeev 是以色列的开发者。它也是 Zend 公司的联合创始人。登陆它的 twitter 上看,它的 twitter 封面有个可爱的女儿,看来外国人也是很爱在社交账号晒女儿的。

其实 PHP 现在大都由社区进行维护了,Zeev 的离职并不一定会有多少影响。

但是这次 Zeev Suraski 在社区中提的这个方案就引起了不少的反响。https://wiki.php.net/pplusplus/faq。 我们可以通过里面的internal邮件 https://marc.info/?l=php-internals&m=156529545007909&w=2 查看整个邮件线。

 

P++的方案

Zeev 的这封邮件的标题很有意思: Bringing Peace to the Galaxy。它希望这个idea 能给社区的强弱类型的争端带来和平,希望能解决强弱类型问题的争论。

基本上 Zeev 是从如何发展 PHP 的角度考虑。现在 PHP 最大的分歧就是是维护动态语言,还是逐渐加入强类型的特性。基本上,如果要增加一些静态语言的类型声明和验证,PHP 的向下兼容性是得不到保证的。但是随着 Rust, Go 等语言的冲击,有一部分开发者逐渐倾向于使用一些强类型的特性。

那么 Zeev 就认为,与其不断在现有的 PHP 版本上对每个特性讨论强弱类型的兼容性,我不如让 PHP 可以支持另外一种“新语法” P++。当然这个 P++ 只是暂定的。在 Zeev 的思考中,它认为 P++ 是一种增强型语言,但是和 PHP 是共存的。它们的调用关系就是 C 和 C++ 的关系,C++ 并不对 C 的所有语法兼容,而是C++ 中是可以调用 C 代码的。换句话说,它觉得我们可以在一个代码文件中共存两种语法的代码段。可能示例如下:

<?php
xxx
?>

<?p++
?>

这样做的好处有几个,首先 PHP 的适用人群扩大了,它满足了不同开发者的不同口味。其次,一些新的特性不用再考虑向下兼容性了。在 P++ 中开发的特性等于是从头开始开发,并不需要考虑 PHP 若干版本的历史兼容问题。会解放新特性的开发进度。

所以说,Zeev 并不是要开发一个新语言,也不是要从 PHP 分支 fork 出一个分支,更像是要创建一种新的语法分支,这个分支我理解主要是针对强类型限制的。而这个语法分支和原先的 PHP 是在同一份代码内。并且随着每次 PHP 的版本,原先弱类型的 PHP和 新类型的 P++ 都会进行修复和增加。

另一种方案

但是紧跟着 Zeev 的这个邮件,Nikita Popov 回复了这个邮件,它提出了反对的声音,并且提出了自己的解决方法。

Nikita 的解决方法是参照 Rust 的版本管理,Rust 基本 2-3 年发布一个大版本,但是 Rust 的编译器能编译所有版本的代码,所以每次发布新版本的时候,如果你的代码是旧版本的,那么还可以继续编译,且不会和新特性有冲突。 https://doc.rust-lang.org/edition-guide/editions/index.html#what-are-editions。Rust 到如今有两个大版本了,2015版本和2018版本。

可以想象,如果引入 Nikita 的这种方式,需要在每个代码文件中(或者粒度更细,到代码块)中标记 PHP 的大版本版本号,比如用年号作为大版本号,今年2019是第一版本,也是默认版本,过两年2021是第二版本。

Nikita 的这种方式目的是保持单一的 PHP 的语法分支,并且新特性也是不需要考虑向下兼容问题。比如假设有2019版本和2021两个 PHP版本。2021版本中语言的新特性在2019版本中是无法使用的。如果你想要使用这些新版本,开发者需要主动做升级修改。(可以想象到时候会有一些自动升级的脚本)。但是如果你不想要修改,那么就在你的所有文件(或者配置)中说明我的项目使用的是2019版本(即使你现在使用的是 PHP 程序的版本是2021)。

 

后续

这封邮件后续的反馈基本都是针对这两种方案展开的。Zeev 的方案基本的缺点就是需要维护两个语言特性的分支,对于有限的语言开发者资源来说,是很吃力的。不少人会担心最后演变成为 Python2 和 Python3 的现状,长期无法合并。而且需要开发者在是使用PHP 语法还是P++ 语法做选择。而 Nikita 的方案更有版本迭代的意味。

我个人更站边 Nikita的这种升级,我觉得这种方案会有一种趋向性,最终大家会渐渐升级到新版本。且更容易落地,开发者只需要维护一套语言特性(相比于 Zeev 的方案更容易落地)。而 Zeev 的这种方案总是会给人一种老版本的 PHP 不想再去增加新特性,所有新特性都加在 P++ 这边更好的感觉。渐行渐远,我感觉最终还真会演变成大家都在开发新语言的态势。

 

参考资料

https://marc.info/?l=php-internals&m=156535343921170&w=2
https://doc.rust-lang.org/edition-guide/editions/index.html#what-are-editions
https://nikic.github.io/
https://www.oschina.net/news/108717/zeev-leave-zend

 

本文:解读 P++提案: P++ vs PHP 孰强孰弱, P++会成为PHP的里程碑吗?

Leave a Reply