文档章节

P++ 的想法: 常见问题( 全文翻译 )

kaffa
 kaffa
发布于 08/12 00:11
字数 3528
阅读 3606
收藏 7
PHP

关键字

PHP, PPlusPlus, FAQ, Zeev Suraski, internals@

P++ 的想法: 常见问题

原文: https://wiki.php.net/pplusplus/faq
时间: 2019 年 8 月 9 日
作者: Zeev Suraski, zeev@php.net

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

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

这到底是怎么回事?

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

  1. PHP 世界有两个大的阵营。第一个大致喜欢 PHP 的动态性,带有强烈的 BC译注2 偏见,并特别强调简单性,另一个更喜欢减掉包袱,拥有更高级、更复杂功能的更严格的语言。
  2. 这里没有“对”或“错”。这两种流派都有效,并具有非常坚定的追随者。然而,创建一种同时迎合这两个阵营的语言则是一项挑战,这也是 internals@ 上争论的一贯的原因。
  3. 该提议是创建一种新的 PHP 方言(代码名 P++),与 PHP 并存,但不受语言背后的历史哲学约束。换句话说,这种新方言本质上可能更加严格,它可能会更加大胆地消除向后兼容,并删除被认为是“包袱”的元素(例如短标签),并添加更复杂的特性,尤其是那些非常适合严格类型化的语言的,而无需为 PHP 方言引入相同的复杂性。
  4. 这不是 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)?”

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

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

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

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

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

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

有哪些挑战?

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

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

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

译注

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

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

相关文章

PHP 联席架构师辞职,原来他想做 P++…

© 著作权归作者所有

kaffa

kaffa

粉丝 1
博文 2
码字总数 8860
作品 0
深圳
人事招聘
私信 提问
加载中

评论(17)

梅开源
梅开源
喜欢严格的去玩java和Cpp不好吗
有精力不如把php从web领域爬出来,像python一样去攻高薪人工智能等行业,让死忠兄弟们赚到钱是最现实的。
x
xytest01
难道php的死忠就不能去学python吗?
梅开源
梅开源
都说了死忠
kut
kut
屁语言
开源春哥
开源春哥
谢谢翻译。
slince91
slince91
现在的严格模式跟没有差不多,有必要p++ ,以后的若语言用处不大
eechen
eechen
Nikita Popov和Dmitry Stogov都是PHP的核心开发者.
他们两者在类型系统上存在严重的分歧.
Nikita Popov支持,而Dmitry Stogov反对.
Dmitry Stogov在两次关于类型的RFC中都投了反对票:
https://wiki.php.net/rfc/scalar_type_hints_v5
https://wiki.php.net/rfc/typed_properties_v2
Dmitry Stogov和鸟哥是PHP7发起者和核心开发者,同时还是PHP的opcache/ffi/jit等开发的领导者.
而Nikita Popov年初加盟了JetBrains的PHPStorm团队,自然要推动PHP在类型上的发展.
Zeev提议P++,可能想调和他们两者的矛盾.
不过我觉得,P++,如果发起投票,Dmitry Stogov依旧会投反对票.
kaffa
kaffa 博主
我很理解 Nikita 的想法,我和他的类似,对Web这个靠人端比近的领域,选择强类型动态更适合。话说 strict_types 还是创始人 Rasmus Lerdorf 开发的,目前 php 是弱类型动态,若发展为强类型动态也挺好的,甚至说不定可实现一个强类型静态模式,像 go 一样编译为依赖一个动态链接库的二进制。
eechen
eechen
在strict_types的投票中,Rasmus Lerdorf投的是反对票,鸟哥和Dmitry Stogov也是反对票,Zend创始人之一Andi也是反对票. 赞同票的则是Nikita Popov和Zend创始人之一Zeev. 可见,不仅核心开发者,连Zend公司的两个创始人,意见都是不统一的.
kaffa
kaffa 博主
eechen 的简述不错,详情可见:https://externals.io/message/106503
eechen
eechen
P++不是一个好想法,我认为甚至是Nikita应该也是不支持的,Nikita应该是想在可选的strict_types的基础上进行完善.一些曾经支持strict_types也直言反对Zeev的P++,比如Andrea Faulds.
高久峰是个大胖子
还是好好发展严格模式比较好
JPer
JPer
<p++
class User {
private String name;
private int age;
User(String name, int age){
this.name = name;
this.age = age;
}
User(String name){
this.name = name;
}
}
p>
x
xytest01
你这门语言就叫 Pavarotti 帕瓦罗蒂吧😂
kaffa
kaffa 博主
叫ppp
kaffa
kaffa 博主
据他说,准备在更广泛的范围内使用严格模式,还可以设置为全局使用,目前严格模式做不到全局。
-_-_-_-_-_-_-_-_-_-_
-_-_-_-_-_-_-_-_-_-_
这与php7的严格模式有什么区别吗?
Zend 创始人提议创建 PHP 方言,暂命名为 P++

P++ 是临时代号,可能会更改。 今日消息,不久前从 Zend 公司离职的 Zeev Suraski 以 PHP 开发组成员的身份提议要创建 PHP 方言,暂命名为 P++。 Zeev 表示,现有的 PHP 继续作为动态语言存在...

局长
08/10
16.1K
65
MySQL细节再探|省时省力|常用MySQL

本文所讲均为,日常工作中常用到的sql语句,另外也是为了节省多次书写耗时所创作。 查看当前使用的数据库: select database(); 查看当前登录的用户: select user(); 连接服务中参数的疑问(...

LeeBoot
2018/05/03
0
0
CGDB调试器的中文帮助手册--《CGDB中文手册》

《CGDB中文手册》是一本由英文版《CGDB Manual》翻译而来的一本手册,CGDB 在开源中国的主页是http://www.oschina.net/p/cgdb,英文原版的《CGDB Manual》在http://cgdb.github.com/docs/cgd...

leeyiw
2013/03/03
5.1K
0
MySQL Workbench 5.1.7 Alpha For Linux 和 OS X 发布

上个星期,我们有一个小组会议,在那里我们可以讨论和计划相关的各种问题和想法,为当前和未来版本的项目做准备。到最后要发布新版本,展现了我们在过去几个星期努力工作成果的时候,我们有了...

红薯
2009/02/04
316
0
“Linux”小程序发布一月总结

一个月前,我们发布了一个小程序“Linux”,可以用来快速查找 Linux 中的命令常用语法。这个小程序中我们收录了上千条 Linux 命令(严格地说,几乎包含了 Unix/BSD 乃至于 OSX 等的全部命令)...

作者: 老王
03/12
0
0

没有更多内容

加载失败,请刷新页面

加载更多

OSChina 周日乱弹 —— 我,小小编辑,食人族酋长

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @宇辰OSC :分享娃娃的单曲《飘洋过海来看你》: #今日歌曲推荐# 《飘洋过海来看你》- 娃娃 手机党少年们想听歌,请使劲儿戳(这里) @宇辰OSC...

小小编辑
今天
484
10
MongoDB系列-- SpringBoot 中对 MongoDB 的 基本操作

SpringBoot 中对 MongoDB 的 基本操作 Database 库的创建 首先 在MongoDB 操作客户端 Robo 3T 中 创建数据库: 增加用户User: 创建 Collections 集合(类似mysql 中的 表): 后面我们大部分都...

TcWong
今天
20
0
spring cloud

一、从面试题入手 1.1、什么事微服务 1.2、微服务之间如何独立通讯的 1.3、springCloud和Dubbo有哪些区别 1.通信机制:DUbbo基于RPC远程过程调用;微服务cloud基于http restFUL API 1.4、spr...

榴莲黑芝麻糊
今天
10
0
Executor线程池原理与源码解读

线程池为线程生命周期的开销和资源不足问题提供了解决方 案。通过对多个任务重用线程,线程创建的开销被分摊到了多个任务上。 线程实现方式 Thread、Runnable、Callable //实现Runnable接口的...

小强的进阶之路
昨天
31
0
maven 环境隔离

解决问题 即 在 resource 文件夹下面 ,新增对应的资源配置文件夹,对应 开发,测试,生产的不同的配置内容 <resources> <resource> <directory>src/main/resources.${deplo......

之渊
昨天
29
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部