PHPジェネリックのケース

<!–

–>

この連載は、単に教えることではなく、PHP にジェネリックを追加するための最も現実的で論理的な道筋を説明することでもあると言って始めました。

同意するかどうかは、このビデオの後でご判断ください。 というわけで、最後に締めくくりの言葉を始めたいと思います。

モノモーフィングまたは具体化されたジェネリックの追加は行われません。 少なくとも、このトピックについて広範な調査を行ったニキータによれば、そうではありません。 どちらのオプションも、パフォーマンスの問題を引き起こすか、妥当な時間内に実現するには PHP のランタイム型チェッカーのコア コードのリファクタリングが多すぎる必要があります。

ただし、ジェネリックがもたらす真の価値について考えてみると、それは実行時の型チェックではありません。 PHP ランタイム型チェッカーが起動し、おそらく型エラーをスローするまでには、既にコードを実行しています。 私たちのプログラムはクラッシュします。 また、私のプログラムのユーザーが「ああ、型エラーだ、大丈夫だ」と言うのを聞いたことがありません。 いいえ、プログラムがクラッシュしました。これで話は終わりです。

PHP のランタイム型チェックは非常に便利なデバッグ ツールです。 しかし、PHP の型システムの価値のほとんどは、静的解析から得られます。

したがって、PHP でジェネリックが必要な場合は、マインド シフトが必要です。

まず、開発者は 静的分析を取り入れる. ここで皮肉なことに、ジェネリックを必要とし、その価値を理解している開発者は、静的型チェッカーの価値も理解しています。 そのため、静的解析を気にしない PHP 開発者のグループがいる一方で、ジェネリックがもたらす価値も気にするべきではありません。 なぜなら、ジェネリックと静的型チェックの 2 つを単純に分離できないからです。

次に、PHP の内部で、静的にチェックされたジェネリックが PHP 内にあると判断された場合。 彼らは、静的解析をコミュニティの責任として任せるべきか、それとも自分たちがその役割を果たさなければならないかを考える必要があります。 作成することによって 仕様 すべての静的アナライザーに従うか、またはそれらを出荷することによって 独自の静的型チェッカー. 2番目の方が間違いなく望ましいですが、それがどんな仕事になるか想像できます。 実績のあるサードパーティ ツールに依存することが問題になるとは思いません。

三番、 タイプジャグリングはもはや不可能です、少なくともジェネリックを使用する場合はそうではありません。 静的型チェッカーを信頼する必要があります。 これは、PHP 開発者があまり慣れていないプログラミング方法ですが、他の多くの言語はまさにこれを行っており、問題なく動作します。 静的型チェッカーは非常に強力で正確です。 PHP 開発者が、静的型付け言語を使用したことがなければ、その力を理解するのは難しいと想像できます。 静的型システムの力を理解するためだけに、Rust、Java、さらには TypeScript などの言語を調べる価値があります。 または、PHP のサード パーティの静的アナライザーの 1 つ (Psalm または PHPStan) の使用を開始することもできます。

要約すると、ジェネリックが静的解析にもたらすすべての利点を備えた PHP でジェネリックが必要な場合は、実行時に消去されるジェネリックが唯一の実行可能なパスであるという事実を受け入れる必要があります。

最後に、私が対処したいいくつかの発言があります。

最初に、私が説明していることは docblock ですでに可能であるという議論があります。 このシリーズの 2 番目の投稿に戻ると、相違点を詳細に説明していることがわかりますが、簡単に要約させてください。

• Docblock は、組み込み構文と同じ重要性を開発者に伝えません。これが、PHP 8 で属性を取得した理由でもあります。 組み込み構文は docblocks よりも価値があります
• また、doc ブロックを使用するときに一般的な注釈がどのように見えるべきかについての公式の仕様もありません。 3 つの主要な静的アナライザーの実装はすべてわずかに異なるため、これは今日大きな問題です。

2 つ目の注意点は、型消去を行っても、リフレクション API を介してジェネリック型情報を公開できることです。 実行時に型情報を完全に削除すべきだと言っているわけではありません。私の最大の関心事は、PHP が実行時にジェネリック型をチェックするべきではないということです。 リフレクションを介してジェネリック型情報を利用できるようにすることで、PHP のコアにどのような影響があるかはわかりません。 だから私はその考えに反対していないということをそこに置いているだけです.

そして最後に、もちろん別の解決策があります。 誰もが理論的に追求できるもの。 過去に証明されたもの: TypeScript. 通常の PHP にコンパイルされる PHP のスーパーセットが存在し、コンパイル中に多くの型チェックやその他の優れた処理を実行する可能性があります。 TypeScript は非常に人気があり、サーバーサイド言語で同様のアプローチを採用する余地がある場合、PHP がおそらく有力な候補になると思います。 ただし、TypeScript は魔法のように一晩で登場したわけではありません。 これは経験豊富な言語設計者によって作成されたものであり、PHP でランタイムを無視するジェネリックを追加するよりもはるかに大きなものです。 しかし、誰が知っているでしょうか。

以上のことを踏まえて、このシリーズが役に立ち、教育的であると感じていただければ幸いです。 ジェネリックについて言いたいことはすべて言いました。 このシリーズを同僚やフォロワーと共有していただければ幸いです。これは重要なトピックであり、状況が変わることを望んでいます。

私は自分のケースを休ませます。