ありがたいことに、そのようなこと（作業負荷が 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 サイトには言いたいことがある!
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
