P++ 的想法: 常見問題（ 全文翻譯 ）
關鍵字
PHP, PPlusPlus, FAQ, Zeev Suraski, internals@
P++ 的想法: 常見問題
原文： https://wiki.php.net/pplusplus/faq
時間: 2019 年 8 月 9 日
作者: Zeev Suraski, [email protected]
這是一份對在 internals@譯註1 上提出的想法的常見問題澄清，它試圖解決許多在隨後討論中被反覆提出的問題。
注：P++ 是一個臨時程式碼命名，未來可能會變化。
這到底是怎麼回事？
試圖將冗長的郵件內容濃縮為幾點：
- PHP 世界有兩個大的陣營。第一個大致喜歡 PHP 的動態性，帶有強烈的 BC譯註2偏見，並特別強調簡單性，另一個更喜歡減掉包袱，擁有更高階、更復雜功能的更嚴格的語言。
- 這裡沒有“對”或“錯”。這兩種流派都有效，並具有非常堅定的追隨者。然而，建立一種同時迎合這兩個陣營的語言則是一項挑戰，這也是 internals@ 上爭論的一貫的原因。
- 該提議是建立一種新的 PHP 方言（程式碼名 P++），與 PHP 並存，但不受語言背後的歷史哲學約束。換句話說，這種新方言本質上可能更加嚴格，它可能會更加大膽地消除向後相容，並刪除被認為是“包袱”的元素（例如短標籤），並新增更復雜的特性，尤其是那些非常適合嚴格型別化的語言的，而無需為 PHP 方言引入相同的複雜性。
- 這不是 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）？”
這裡沒有對或錯。這兩種觀點都有效。當我們研究在這兩個相互矛盾的觀點之間架起橋樑的可能的解決方案時，沒有太多可用的方案：
- 堅持使用動態PHP。這將不會被更嚴格語言的支持者所接受。
- 向嚴格的PHP發展。動態語言的支持者不會接受這一點。
- 分叉程式碼庫。無論如何完成，都是所有參與者的淨損失選項。 這樣做沒有技術優勢，即使我們想要（我們不想要），我們也沒有足夠的貢獻者去做。
- 提出一些創意解決方案，以滿足雙方觀眾的需求。 這就是該提案試圖做的。它在保持專案本身統一的同時，也確保兩種方言之間的永久互操作性。這雖然會有一定程度的碎片化，但它仍然是滿足每個人的主要需求的最小可能。
這與 Nikita譯註5 版本的想法有何不同？
這兩個想法之間有許多相似之處，但也存在一些實質性差異。 請注意，這是基於對版本方法的有限理解，因此部分可能缺乏，不準確或不正確。
- 在這個提議中，有一個明確的目標是保持當前動態型別的 PHP，作為一個長期的，完全支援的，平等的對等方言。 發版本的方法將當前行為視為“遺留”。 這意味著它可能會被勸止（使用），然後在某些時候棄用和刪除。
- 推出策略完全不同。 P++ 提案旨在首先關注相容性破壞元素，例如嚴格的操作、型別轉換邏輯的更改、陣列索引處理、需要變數宣告等等，並且旨在在 P++ 的第一期提供它們。這樣做的目的是允許新專案/框架重新開始，而不需知道在引入更多相容性更改時，他們可能不得不在一兩年內進行重大改寫。 版本化提案似乎沒有這樣的目標，而是旨在逐步新增/更改 PHP 中的元素。
- 與推出方式相關，版本化方法不允許只有兩種方言，而是任何數量的方言。我們可能有 PHP2020 方言，以及 PHP2022 方言和 PHP2027 方言。 如果我們全部保留它們，實際上這可能會增加我們的維護複雜性。
- 該提議還提到了 PHP 與 P++（保守與積極）的不同打破向後相容策略，而版本化方案可能根本不會涉及該主題。
- 版本提案與此提案的定位/營銷方面並不完全相同。
重要的是，要注意這兩個想法不一定是相互排斥的。 我們可以介紹 P++ 並使用版本進行改進，特別是當證明很難將所有重要的變化都放到 P++ 的第一期中。
有哪些挑戰？
在我們能執行第一個 P++ 應用程式之前，不乏挑戰。
- 我們需要獲得支援。這意味著，兩派的人都需要放棄讓 PHP 完全動態或完全型別化的夢想，而忽略那些與他們想法不同的人。這似乎是一個非常重大的挑戰。
- 為獲得成功，P++ 第一個版本應該處理來自 PHP 的所有，或至少大多數相容性破壞的更改，以便切換（可能相當痛苦）的開發人員不必在未來重新稽核/徹底重構他們的程式碼。一些人表示擔心，由於我們的開發人員能力有限，他們可能過於樂觀，無法在一期釋出。一旦我們對列表的內容有了更好的瞭解，我們就必須對此進行評估。 請注意，這並不意味著我們需要在第一個期中實現我們可能對 P++ 提出的所有想法，只是我們應該優先考慮會觸發大量終端使用者程式碼重寫的元素，並嘗試在我們的第一版之前處理它們。
- 當然,最具挑戰性的——我們需要為這種新方言找到一個合理的名字。
pplusplus/faq.txt · 最後修改： zeev 於 2019/08/09 21:44
譯註
- internals@：PHP 內部開發人員郵件列表。這裡涉及 PHP 的開發機制，當內部討論成熟後，會公開在 externals，通常用來提交 RFC 和釋出版本通知。
- BC：即 Backward Compatibility，向後相容，也叫向下相容，相容過去的版本，即升級的軟體要考慮舊版本的相容性，比如，Office 2019 的 Word 預設使用 .docx 檔案格式，但也可以開啟 Office 2017/2013/2010，甚至是 2003 的 .doc 格式。相對的概念叫做 FC，即 Forward Compatibility，向前相容，也叫向上相容，即升級的軟體會考慮對未來的相容性。這在軟體中通常為一個確定的介面和約定，未來依然遵循，即可實現向前相容。
- RFC：即 Request for Comments，語言特性的加入，以及標準化變更管理的方法，通常加入新特性時，會為新特性提交 RFC 並給出例子，變更委員會評估通過後，語言會合入實現的原始碼，併入新版本。
- 新的基點：a clean slate，美國習語，即不計過去新的開始。
- Nikita：一位 internals@ 上的發言者，提議在版本中加入特性。順便提一句，美劇《Nikita》值得一看。
（本文翻譯為筆者原創 ，限於水平有限，如翻譯中有不妥的地方請回復留言，如轉載請註明出處：IT桃花島）