PHP の新しいブランチ: P++、PHP が弱い型付け言語であるとまだ言う勇気がありますか?

要約:PHP 言語の創始者であるラスムス レルドルフは 1968 年生まれで今年 51 歳で、1995 年に Personal Home Page Tools という名前で PHP 1.0 をリリースしました。 Yahooの検索の衰退で彼の栄光は影を潜めた。

1997 年、イスラエルのプログラマー Zeev Suraski と Andi Gutmans が Zend Company の PHP 言語開発に参加し、PHP 3、PHP 4、PHP 5 をリリースしました。PHP 6 は存在せず、現在は PHP 7 であることに注意してください。 Zeev Suraski は 1975 年生まれで、Zend で 20 年間働いています。もしかしたら、言語、アーキテクチャ、ライブラリの開発の方向性が見つからないのかもしれません。

数日前 Zeev Suraski 氏が Zend からの辞任を発表しました . 業界は非常に驚きました. PHP 7 最適化開発者の Bird Brother 氏は、これは以前からあったことだと述べました長い間計画されていました。 Zeev Suraski が辞任し、P をやりたかったことが判明しました。それでは、P とは何ですか? 「P idea: FAQ」を通じて回答し、著者が全文を翻訳しました。

原文の翻訳:

これは、internals@(internals@: PHP 社内開発者向けのメーリング リストです。ここに FAQ の説明があります) PHP (内部の議論が成熟すると外部に公開され、RFC の提出やリリース通知の提出によく使用されます) に関する開発メカニズムについて提示されたアイデアの一部であり、その後の議論で繰り返し提起された問題の多くに対処しようとしています。 . .

注: P は暫定的なコード名であり、将来変更される可能性があります。

一体何が起こっているのでしょうか?

長い電子メールの内容をいくつかのポイントに要約してみます:

1. PHP の世界には 2 つの大きな陣営があります。 1 つ目は、一般的に強い BC バイアスを伴う PHP のダイナミクスを好みます (BC: 後方互換性、下位互換性とも呼ばれ、過去のバージョンとの互換性。つまり、アップグレードされたソフトウェアは古いバージョンとの互換性を考慮する必要があります。たとえば、Office の Word) 2019 では既定で .docx ファイル形式が使用されますが、Office 2017/2013/2010、さらには 2003 でも .doc 形式を開くこともできます。相対的な概念は FC と呼ばれ、前方互換性であり、前方互換性があり、とも呼ばれます。上位互換性。つまり、アップグレードされたソフトウェアは将来の互換性を考慮します。これは通常、ソフトウェア内の特定のインターフェイスと規則であり、上位互換性を達成するために将来も引き続き従われます。）、シンプルさを特に重視し、また、荷物を減らし、より高レベルで複雑な機能を備えたより厳格な言語を使用することを好む人もいます。

2. ここには「正しい」も「間違い」もありません。どちらのジャンルも有効であり、熱心なファンがいます。ただし、両方の陣営に対応する言語を作成するのは困難であり、内部関係者@に関する議論の一貫した原因となっています。

3. この提案は、PHP と共存しながら、言語の背後にある歴史的哲学に束縛されない、新しい PHP 方言 (コード名 P ) を作成することです。言い換えれば、この新しい方言は本質的により制限的なものになる可能性があり、下位互換性をより大胆に排除し、「荷物」とみなされる要素 (短いタグなど) を削除し、より複雑な機能を追加する可能性があります。 PHP 方言と同じ複雑さを導入することなく、厳密に型指定された言語に適しています。

4. これは PHP コードの分岐ではありません。コードベースは同じであり、それに取り組む開発者も同じです。コードの大部分は同じです。 2 つの方言間の特定の相違点のみが、異なる方法で実装されます。これは、PHP 7 で strict_types が行ったことと似ていますが、規模が大きいだけです。

一部の人々が短いタグを放棄できないという理由だけで、本当にこれを行うつもりですか?

これは短いタグとは関係ありません。「短いタグの廃止 RFC (RFC: Request for Comments、言語機能の追加、および標準化された変更管理方法。通常、新しい機能が追加されるときは、新しい機能が追加されます)」機能は RFC に提出され、例が示されます。変更委員会が評価して承認した後、言語は実装ソース コードに統合され、新しいバージョンに組み込まれます。)」は、このアイデアの主な動機ではありません。この提案の目標はより野心的なものであり、PHP に明確なビジョンを提供し、両陣営が望むものを与えることで最終的に 2 つの陣営間の緊張を解決したいと考えています。

PHP をフォークする理由

これはフォークではありません。コードベースはまったく同じで、同じ人によって開発されます。バイナリはまったく同じになります。PHP をインストールすると P もインストールされ、その逆も同様です。同じバイナリで、PHP、P、または PHP/P を組み合わせたアプリケーションを実行できます。

ファイルがどのように P ファイルとして「マーク」されるかは明らかではありませんが、ファイルの先頭に次のような特別なマークが付けられている可能性があります。名前空間全体が P のメソッドでマークされていることが判明する可能性があるため、フレームワークは個々のファイルを明示的に P としてマークする必要はありません。

これは、開発ワークロードが 2 倍になり、internals@ の貢献者がすでに少なくなっていることを意味します。どうやって対処すればいいのでしょうか？

ありがたいことに、そのようなこと（作業負荷が 2 倍になる）を意図したものではありません。コードの大部分は、ソース コードとランタイムの両方で、PHP モードと P モードの間で共有されます。

実行中のファイルが PHP ファイルであっても P ファイルであっても、データ構造、主要なサブシステム、拡張機能、Web サーバー インターフェイス、OPcache、およびその他すべてのコードはまったく同じコードになります。追加の開発オーバーヘッドは、PHP と P の違いだけです。

実際、これは、特定のコード スニペットの 2 つのバージョンを維持する必要があることを意味し、P には PHP と比較して追加のチェックがある可能性があるため、あちこちに if() ステートメントが含まれることになります。ただし、より厳密なバージョンの PHP に移行する場合は、いずれにしてもこれらの要素を導入する必要があります。さらに、厳密派の人々でさえ、移行パスを提供せずに将来の厳密なバージョンに移行することは推奨しません。実際、このアプローチに伴う労力は他のほぼすべてのアプローチと同様です。

より厳格な PHP 8/9 に移行するとき、永久にメンテナンスされる PHP 7.4 の長期メンテナンス リリースを開発しないのはなぜでしょうか?

このアプローチには多くの問題があります。これにより、機能やパフォーマンスの更新が行われずに、巨大な動的優先キャンプが保留されたままになるという事実を無視したとしても、開発作業の観点からは非現実的です。これは、事実上のフォークを意味するこの提案とは異なります。

PHP と P のどちらかを選択する必要がありますか? ＃＃＃＃＃＃＃＃＃はいといいえ。上で述べたように、一方をインストールするともう一方もインストールされるため、アプリケーションに関する限り、1 つのサーバー上で両方の方言を実行できます。ただし、実際には、厳密型の場合と同様に、プロジェクトや個人がどちらかを選択して標準化することがよくあります。

同じアプリケーション内で PHP と P を混在させることはできますか? ＃＃＃＃＃＃＃＃＃はい。正確なメカニズムを決定する必要がありますが、コードが PHP であるか P であるかの指定は、リクエスト レベルではなくファイル レベルで行われます。 1 回の実行 (リクエスト) で、両方の方言からのさまざまなファイルをロードできます。 PHP ファイル内のコードは PHP セマンティクスとして動作し、P ファイルのコードは P セマンティクスとして動作します。これも strict_types に似ています。

これは最初はぎこちなく聞こえるかもしれませんが、非常に実用的な使用例があるかもしれません。たとえば、PHP アプリケーションは P のみのフレームワークを使用し、その逆も同様です。 C と C に精通している人にとって、これはある程度似ています。

これは、PHP はもう進化しないということですか?すべての新機能は P に導入されるのでしょうか?

いいえ、それは単に、異なる展開になることを意味します。厳密性および型関連の機能は P でのみ使用でき、P ファイルでのみ使用できます。 PHP には下位互換性のバイアスが残ります (これは、下位互換性が決して壊れないという意味ではなく、そのようなケースごとに適切な ROI ケースが存在する必要があるというだけです)。

ただし、エンジン パフォーマンスの向上 (JIT など)、拡張機能の開発、非同期関連の新しい機能など、これに関係のない機能は、PHP と P の両方で利用できます。

この方法の利点は何ですか?

このアプローチには多くの利点があります。まず、内部関係者の両方の陣営に優れたソリューションを提供します@。 PHP の動的な性質を好む人はそれをそのまま使用できますが、より厳密に型指定された言語を好む人は、PHP の制限なしで PHP を入手することもできます。別の方法は、一方の陣営の勝利が他方の陣営の敗北であり、その逆も同様であるゼロサム ゲームです。

これにより、最小限の労力で視聴者全体をサポートできる優れた技術ソリューションを設計できるだけでなく、近年の内部事情に関する主要な論争の原因を解決することができます。 最後に、このドキュメントの読者のほとんどは技術者である可能性が高いですが、Launch P は過去に関係なく新しい出発点からやり直すことになり、潜在的にポジショニングとブランディングに大きな利点があることに注意してください。 PHP を使用していない企業、開発マネージャー、および個人の開発者は、PHP 8.0 や PHP 9.0 のリリースよりも P のリリースに注目する可能性が高くなります。

ユーザーベースを分断する危険はありませんか?

ある意味では、私たちもそうなのです。しかし、これはアイデアの欠陥ではなく、すでに存在する現実の現れです。

上で述べたように、世の中には PHP の動的な性質を好み、PHP をますます型指向にしようとすることに慎重な人がたくさんいます。 一方、別のグループの人々は PHP を見てこう考えています。「なぜこんなに遅くなっているのに、この動的でナンセンスな作業をついにやめようか?」ここには正解も不正解もありません。どちらの見解も有効です。これら 2 つの相反する観点を橋渡しする可能性のある解決策を検討したところ、利用可能な解決策はあまりありませんでした:

1. 動的 PHP を使い続ける。これは、より厳格な表現の支持者には受け入れられないでしょう。

2. 厳密な PHP に向けて開発します。動的言語の支持者はこれを受け入れません。

3. コードベースをフォークします。どのように実行されたとしても、参加者全員にとって純損失の選択肢となります。これを行うことに技術的な利点はありません。また、そうしたいと思ったとしても (実際にはそうではありませんが)、それを行うのに十分な貢献者がいないでしょう。

4. 両方の視聴者のニーズを満たす創造的なソリューションを考え出します。それがこの提案がやろうとしていることです。これにより、プロジェクト自体の統一を維持しながら、2 つの方言間の永続的な相互運用性が保証されます。これにはある程度の断片化がありますが、それでも全員の主なニーズを満たすために可能な最小限のものです。

これは、ニキータ (バージョンに機能を追加することを提案した内部事情に関する講演者@) のアイデアとどう違うのですか。ところで、アメリカのテレビ シリーズ「ニキータ」は見る価値があります。 。） バージョン？

2 つのアイデアには多くの類似点がありますが、いくつかの大きな違いもあります。これはバージョン方法論の限られた理解に基づいているため、不足している部分、不正確な部分、または不正確な部分がある可能性があることに注意してください。

1. この提案には、現在の動的型付け PHP を長期的に完全にサポートされる同等のピア言語として維持するという明確な目標があります。リリース アプローチでは、現在の動作を「レガシー」として扱います。これは、推奨されず (使用されず)、ある時点で非推奨となり削除される可能性があることを意味します。

2. 立ち上げ戦略はまったく異なります。 P 提案では、厳密な操作、型変換ロジックの変更、配列インデックスの処理、変数宣言の要求など、互換性を損なう要素にまず焦点を当て、それらを P の創刊号で提供することを目指しています。この目的は、互換性に関するさらなる変更が導入された場合に、1 ～ 2 年以内に大幅な書き換えが必要になる可能性があることを知らずに、新しいプロジェクト/フレームワークを新たに開始できるようにすることです。バージョン管理の提案にはそのような目標はないようですが、代わりに PHP の要素を段階的に追加/変更することを目的としています。

3. ロールアウト アプローチに関連して、バージョニング アプローチでは 2 つの方言だけを許可するのではなく、任意の数の方言を許可します。 PHP2020 方言だけでなく、PHP2022 方言や PHP2027 方言も存在する可能性があります。それらをすべて保持すると、実際にはメンテナンスが複雑になる可能性があります。

4. この提案では、PHP と P (保守的なものと積極的なもの) に関するさまざまな下位互換性を破る戦略についても言及していますが、バージョン管理スキームではその話題にはまったく触れていない可能性があります。

5. バージョン提案には、この提案とまったく同じポジショニング/マーケティングの側面がありません。

これら 2 つのアイデアは必ずしも相互に排他的ではないことに注意することが重要です。特に、すべての重要な変更を P の最初の号に適合させることが難しいことが判明した場合は、 P を導入し、バージョンを使用して改善することができます。

課題は何ですか?

最初の P アプリケーションを実行するまでには、課題が尽きませんでした。

1.サポートが必要です。これは、通路の両側にいる人々は、PHP を完全に動的にする、または完全に型指定するという夢を諦め、自分たちと異なる考え方をする人を無視する必要があることを意味します。これは非常に重要な課題であると思われます。

2. 成功するには、最初のバージョンの P は、PHP からの互換性を損なう変更のすべて、または少なくともほとんどを処理して、乗り換える開発者が (おそらく非常に苦痛を伴う) 再訪する必要がないようにする必要があります。コードをリファクタリングします。開発者の能力が限られているため、楽観的すぎて 1 回の号でリリースできないのではないかと懸念する人もいます。リストの内容を理解したら、これを評価する必要があります。これは、最初の問題で P について考えられるすべてのアイデアを実装する必要があるという意味ではなく、多くのエンドユーザー コードの書き換えを引き起こす要素に優先順位を付け、最初のリリースでそれらに対処する前にそれを試行する必要があることに注意してください。 。

3. もちろん、最も難しいことは、この新しい方言に適切な名前を見つける必要があることです。

関連する推奨事項:

1. php は世界で最高の言語です。

2. PHP はもう 10 年前のものです前の Bird サンプル

3. PHP 7.4 は 2019 年 12 月にリリースされる予定です

4. 2019Why Will we PHP を使い続けますか?

5. プログラマーはなぜ PHP をハッキングするのでしょうか? PHP 中国語 Web サイトには言いたいことがある!