PHP の可能性 – Stitcher.io

PHP 開発者としてのあなたの人生がどのように変わるか疑問に思ったことはありませんか? 1 欲しい機能が追加されましたか？ 私はすでに何度も思考実験を行っており、驚くべき結論に達しました。

たとえば、PHP の強い型に関する議論を見てみましょう。 私を含め、多くの人がより良い型システムを望んでいます。 PHP の強い型は、間違いなく私の日常業務に影響を与えるでしょう。 強力な型だけでなく、ジェネリック、より優れた分散型、変数型も必要です。 PHP の型システム全般の改善は、私のプログラミング ライフに大きな影響を与えるでしょう。

では、解決策にたどり着くのを妨げているものは何でしょうか?

# 型理論

型システムについて話すときに使用される語彙について、誰もが同意するわけではありません。 そこで、ここで使用するいくつかの用語を明確にしましょう。

強いタイプか弱いタイプか 定義後に変数の型を変更できるかどうかを定義します。 簡単な例: 変数があるとします $a="test";、これは文字列です。 たとえば、その変数を別のタイプに再割り当てできます $a = 1;、整数。

PHP は弱い型付けの言語であり、より現実的な例でこれを説明できます。

$id = '1'; 

function find(int $id): Model

    



find($id);

最新の PHP では、厳密な型を使用することでこれらの問題を回避できると思うかもしれませんが、それは完全に真実ではありません。 厳密な型を宣言すると、他の型が関数に渡されなくなりますが、関数自体で変数の値を変更することはできます。

declare(strict_types=1);

function find(int $id): Model

    $id = '' . $id;

    


find('1'); 

find(1); 

私が言ったように: PHP の型システムは弱いです。 型ヒントは、その時点での変数の型のみを保証し、変数が持つ可能性のある将来の値については保証しません。

強いタイプは弱いタイプよりも優れていると言っているのですか? いいえ。ただし、強力な型には興味深い特性があります。いくつかの保証が付属しています。 変数の型が変更不可能な場合、予期しない動作の全範囲が発生しなくなります。

おわかりのように、厳密に型付けされたプログラムがコンパイルされた場合、そのプログラムが弱く型付けされた言語に存在する可能性のあるさまざまなバグを持つことは不可能であることが数学的に証明されています。 言い換えれば、強力な型は、コードが実際に想定どおりに動作するというより強力な保証をプログラマーに与えます。

これは、強く型付けされた言語にバグがないという意味ではありません! バグのある実装を完全に作成できます。 しかし、厳密に型指定されたプログラムが正常にコンパイルされると、そのプログラムで特定の一連のバグやエラーが発生しないことが確実になります。

強い型と弱い型に関するトピックをさらに掘り下げたい場合は、Gary Bernhardt によるこのビデオから始めることをお勧めします。 型についてさらに詳しく説明するだけでなく、Gary は型の議論全体における重要な考え方についても説明しています。

# 型チェック時

私たちは話しました 強い と 弱い タイプ、どうですか 静的 と 動的 種類？ – ここからが本当に面白くなり始めます。

ご存じのとおり、PHP はインタープリター言語です。 これは、PHP スクリプトが実行時にコンパイルされることを意味します。 PHPを実行しているサーバーにリクエストを送信すると、プレーンなものが取得されます .php ファイルを開き、その中のテキストをプロセッサが実行できるものに解析します。

ところで、これは PHP の長所の 1 つです。スクリプトを記述し、Web ページを更新し、すべてがそこにあるというシンプルさです。 これは、実行する前にコンパイルする必要がある言語と比べて大きな違いです。

ただし、欠点があります。パフォーマンスです。 そして、これを特定するのは難しくありません。実行時に実行するタスクが増えるほど、パフォーマンスへの影響が大きくなります。 PHP エンジンが処理しなければならない多くのタスクの 1 つですか? 型チェック。

PHP は実行時に変数の型をチェックするため、多くの場合、 動的に型付けされた 言語。 あ 静的に型付けされた 一方、言語では、コードが実行される前にすべての型チェックが行われます。

ちょっと待ってください – あなたの言うことは聞こえます – これは PHP の可能性と何の関係があるのでしょうか?

—私たちはそれに行きます。

# これが PHP にとって何を意味するか

何を話しているのか理解できたので、今日は PHP の型システムを見てみましょう。

理論を理解した後、PHP が 動的、弱い型付け 言語。 と それは何も悪いことではありません!

一方、興味深いことに、多くの人が PHP の型システムの改善を求めています。 これは、PHP でのそのような型システムの意味を理解しているという意味ではありませんが、私たちの多くは次のように感じています。 自然な衝動 より良い型システムのために。 多くの開発者は、より良い型システムが実際に役立つ実生活の日常的な状況を指摘できると確信しています。

明白な例を 1 つ挙げると、ジェネリクスの問題です。 配列に 1 種類の要素のみが含まれるようにするためか、ORM の抽象化を改善するためか、多くの人が PHP でのジェネリックを求めています。

問題は、PHP の現在の型パラダイムで実現可能な、より複雑な型システムを作成できるかということです。 そして答えは、部分的にはイエスです – 確かに。 現在の動的な弱い​​型システムには改善できる部分があります。

PHP 7.0 および 7.1 で追加された型ヒントは、多くの PHP 開発者にとって便利です。 Levi Morrison は、特性のジェネリックに取り組んでいます。 また、internals メーリング リストでは、型システムに関する非常に活発な議論が行われています。

でも: 非常に重要な点が抜けています。 PHP のランタイム型システムを改善しようと努力している限り、私たちは常に膨大なパフォーマンス コストに対処しなければなりません。

# 静的型システムの利点

これは、ラスムス・ラードルフがこのトピックについて述べなければならないことです。

RFC がコンパイル時の静的解析エンジンを PHP 自体に組み込む計画だったとしたら、それは興味深いことです。 しかし、それは大規模なプロジェクトです。

— ラスムス

コードを実行する前に静的に型チェックできる PHP コードを記述できる可能性を想像してみてください。 PHPStan や Psalm などのツールはすでに多くの静的分析を行っていますが、私の意見では、さらに一歩先を行くことができます。 これができるとしましょう。

class List<T>

    private array $list;
    
    

これが有効な PHP コードだったらどうでしょうか? そして、実行時エンジンが単純にそれを無視し、PHP エンジンの一部が実行前にすべての型チェックを実行できるとしたら?

これは、私の意見では、docblock に依存し、PHP で書かれている Psalm と PHPStan の場合、コア PHP エンジンの恩恵を受けられないスタンドアロン ツールよりも優れたソリューションです。

誤解しないでください。このようなツールは、より大きな目標に向けた最初の重要なステップです。 ここでやめるべきではないと思います。

より良い型システムの必要性は明らかです。 多くのプログラマーは、現在可能である以上のことを自然に切望しています。 これは、PHP コミュニティだけで発生するものではありません。Rust などの最新の言語や、JavaScript 用の TypeScript などのスーパーセットを見てください。

したがって、PHP の答えはコアに組み込まれている機能にあるのかもしれません。おそらく、追加の型チェックで PHP にコンパイルされるスーパーセットにあるのかもしれません。 ところで、最後の 1 つは既に試みられています: HHVM のハック。

3 番目のオプションもあります。これは、すべてのプログラマーが時々自問すべき質問です。 私たちのニーズに合わせて PHP を劇的に変更する必要がありますか?それとも、基準のフレームを変更して、それらのニーズにより適した他の言語を検討する必要があるでしょうか?

そのツールの方が自分のニーズに合っているのであれば、仕事に別のツールを使用することは恥ずべきことではありません。 結局のところ、プログラミング言語はそれだけではありませんか? 道具。