1997年，以色列程序员ZeevSuraski及AndiGutmans参加了Zend公司的PHP言语开发，发布了PHP3,PHP4,PHP5，留意没有PHP6，再到现在的PHP7。1975年出生的ZeevSuraski在Zend作业了20年。也许是在言语、架构和库的作业上找不到开展方向了。
前几天ZeevSuraski宣告从Zend离职，业界比较惊奇，PHP7优化的开发者鸟哥说是这是早已预定好的事。原来ZeevSuraski辞去职务，他想做P++，那P++是啥？他经过《P++idea:FAQ》进行了回答，笔者作了全文翻译。
原文翻译：
这是一份对在internals@（internals@：PHP内部开发人员邮件列表。这儿触及PHP的开发机制，当内部评论成熟后，会公开在externals，一般用来提交RFC和发布版别告诉。）上提出的主意的常见问题弄清，它企图处理许多在随后评论中被重复提出的问题。
注：P++是一个临时代码命名，未来或许会改变。
这到底是怎么回事？
企图将冗长的邮件内容浓缩为几点：
1.PHP国际有两个大的阵营。第一个大致喜爱PHP的动态性，带有强烈的BC成见（BC：即BackwardCompatibility，向后兼容，也叫向下兼容，兼容曩昔的版别，即升级的软件要考虑旧版别的兼容性，比方，Office2019的Word默许运用.docx文件格式，但也能够翻开Office2017/2013/2010，乃至是2003的.doc格式。相对的概念叫做FC，即ForwardCompatibility，向前兼容，也叫向上兼容，即升级的软件会考虑对未来的兼容性。这在软件中一般为一个确认的接口和约好，未来仍然遵从，即可完成向前兼容。），并特别强调简单性，另一个更喜爱减掉包袱，具有更高级、更复杂功用的更严厉的言语。
2.这儿没有“对”或“错”。这两种流派都有效，并具有十分坚定的追随者。可是，创立一种一起迎合这两个阵营的言语则是一项应战，这也是internals@上争辩的一贯的原因。
3.该提议是创立一种新的PHP方言（代码名P++），与PHP并存，但不受言语背面的前史哲学束缚。换句话说，这种新方言本质上或许愈加严厉，它或许会愈加斗胆地消除向后兼容，并删去被认为是“包袱”的元素（例如短标签），并添加更复杂的特性，尤其是那些十分合适严厉类型化的言语的，而无需为PHP方言引进相同的复杂性。
4.这不是PHP代码分支。代码库将是同一个，在该代码库上作业的开发人员是相同的。绝大多数代码都是相同的。只要两种方言之间的特定差异点才会有不同的完成。它有点相似于PHP7中的strict_types所做的，仅仅在更大的范围内。
咱们真的要做的便是由于有些人不能抛弃短标签吗？
这与短标签无关，“弃用短标签RFC（RFC：即RequestforComments，言语特性的参加，以及标准化改变管理的办法，一般参加新特性时，会为新特性提交RFC并给出例子，改变委员会评估经过后，言语会合入完成的源码，并入新版别。）”不是这个主意的首要动力。这个提案的方针是更有野心，它是为PHP供给一个明晰的愿景，并希望经过向两个阵营供给他们想要的东西来终究处理两方的紧张关系。
为什么要分叉PHP？
这不是分叉。代码库将彻底相同，它将由相同的人开发版别。二进制文件将彻底相同，假如你安装PHP，你也将安装P++，反之亦然。相同的二进制将运转PHP，P++或组合PHP/P++的应用程序。
尽管现在还不清楚如何将一个文件“符号”为P++文件，但它或许是文件顶部的某种特别符号，例如：
此外，咱们或许会找到将整个命名空间符号为P++的办法，因而，结构不必将每个单独的文件明确符号为P++。
这意味着咱们的开发作业量增加了一倍，而internals@的贡献者现已很低（low）了。咱们如何处理？
值得幸亏的是，这并不意味着是那样（作业量增加了一倍）。绝大多数代码将在PHP形式和P++形式之间共享——包括源代码和运转时。
无论运转的文件是PHP仍是P++文件，数据结构、要害子系统、扩展、Web服务器接口、OPcache以及其他一切代码都将是彻底相同的代码。仅有的额定开发开支会是PHP和P++之间的差异部分。
的确，这意味着咱们有必要保护某些代码片段的两个版别，而且咱们在各个地方都会有一些if()句子，由于与PHP相比，P++或许会有额定的查看。可是，假如咱们要转向更严厉的PHP版别，这些元素无论如何都有必要引进。此外，即使是严厉阵营中的人，也不建议咱们在没有供给迁移途径的情况下转向未来严厉版别——实际上，这种办法所触及的尽力和几乎任何其他的办法都是相似的。
当咱们转向更严厉的PHP8/9时，为什么不仅仅开发一个永久保护的PHP7.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++的推出，而不是PHP8.0或PHP9.0的推出。
咱们不是冒着分裂用户群的风险吗？
在某种程度上，咱们是。但这不是这一主意的缺陷，而是实际现已存在的表现。
如上所述，那里有很多人喜爱PHP的动态本质，而且谨慎地看待尝试使其越来越多地面向类型。
与此一起，还有另外一群看着PHP的人，自己在想：“为什么它变得如此缓慢，以至于我终究要抛弃这动态的废材（原文：dynamicnonsense）？”
这儿没有对或错。这两种观念都有效。当咱们研究在这两个彼此对立的观念之间架起桥梁的或许的处理计划时，没有太多可用的计划：
1.坚持运用动态PHP。这将不会被更严厉言语的支撑者所接受。
2.向严厉的PHP开展。动态言语的支撑者不会接受这一点。
3.分叉代码库。无论如何完成，都是一切参与者的净损失选项。这样做没有技术优势，即使咱们想要（咱们不想要），咱们也没有满意的贡献者去做。
4.提出一些构思处理计划，以满意两边观众的需求。这便是该提案企图做的。它在坚持项目自身统一的一起，也保证两种方言之间的永久互操作性。这尽管会有一定程度的碎片化，但它仍然是满意每个人的首要需求的最小或许。
这与Nikita（一位internals@上的发言者，提议在版别中参加特性。趁便提一句，美剧《Nikita》值得一看。）版别的主意有何不同？
这两个主意之间有许多相似之处，但也存在一些实质性差异。请留意，这是基于对版别办法的有限理解，因而部分或许缺乏，不准确或不正确。
1.在这个提议中，有一个明确的方针是坚持当前动态类型的PHP，作为一个长时间的，彻底支撑的，平等的对等方言。发版别的办法将当前行为视为“遗留”。这意味着它或许会被劝止（运用），然后在某些时候弃用和删去。
2.推出战略彻底不同。P++提案旨在首要关注兼容性损坏元素，例如严厉的操作、类型转化逻辑的更改、数组索引处理、需求变量声明等等，而且旨在在P++的第一期供给它们。这样做的意图是允许新项目/结构重新开始，而不需知道在引进更多兼容性更改时，他们或许不得不在一两年内进行重大改写。版别化提案似乎没有这样的方针，而是旨在逐步添加/更改PHP中的元素。
3.与推出方式相关，版别化办法不允许只要两种方言，而是任何数量的方言。咱们或许有PHP2020方言，以及PHP2022方言和PHP2027方言。假如咱们悉数保留它们，实际上这或许会增加咱们的保护复杂性。
4.该提议还提到了PHP与P++（保存与积极）的不同打破向后兼容战略，而版别化计划或许根本不会触及该主题。
5.版别提案与此提案的定位/营销方面并不彻底相同。
重要的是，要留意这两个主意纷歧定是彼此排挤的。咱们能够介绍P++并运用版别进行改进，特别是当证明很难将一切重要的改变都放到P++的第一期中。
有哪些应战？
在咱们能运转第一个P++应用程序之前，不乏应战。
1.咱们需求取得支撑。这意味着，两派的人都需求抛弃让PHP彻底动态或彻底类型化的梦想，而疏忽那些与他们主意不同的人。这似乎是一个十分重大的应战。
2.为取得成功，P++第一个版别应该处理来自PHP的一切，或至少大多数兼容性损坏的更改，以便切换（或许适当苦楚）的开发人员不必在未来重新审阅/彻底重构他们的代码。一些人表示忧虑，由于咱们的开发人员能力有限，他们或许过于乐观，无法在一期发布。一旦咱们对列表的内容有了更好的了解，咱们就有必要对此进行评估。请留意，这并不意味着咱们需求在第一个期中完成咱们或许对P++提出的一切主意，仅仅咱们应该优先考虑会触发大量终究用户代码重写的元素，并尝试在咱们的第一版之前处理它们。
3.当然,最具应战性的——咱们需求为这种新方言找到一个合理的姓名。
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
