摘要：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 的推出。
我們不是冒著分裂用戶群的風險嗎？
在某種程度上，我們是。但這不是這想法的缺陷， 而是現實已經存在的表現。
如上所述，那裡有很多人喜歡 PHP 的動態本質，並且謹慎地看待嘗試使其越來越多地面向類型。
與此同時，還有另外一群看著PHP 的人，自己在想：「為什麼它變得如此緩慢，以至於我最終要放棄這動態的廢材（原文：dynamic nonsense）？ ”
這裡沒有對或錯。這兩種觀點都有效。當我們研究在這兩個相互矛盾的觀點之間架起橋樑的可能的解決方案時，沒有太多可用的方案：
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. 當然,最具挑戰性的－我們需要為這種新方言找到一個合理的名字。
相關推薦：
