PHP 8.3 には次の新機能があります。 #(Override) 属性。 これは他の言語ではすでに知られている機能ですが、それが何をするのか知らない場合のために要約してみましょう。
メソッドをマークする #(Override) 属性は、あなたが 知る このメソッドは親メソッドをオーバーライドしています。 したがって、それが行う唯一のことは、意図を示すことです。
なぜそれが重要なのでしょうか? メソッドをオーバーライドしていることはすでにご存知ですよね? さて、これら 2 つのクラスを想像してみましょう。
abstract class Parent
{
public function methodWithDefaultImplementation(): int
{
return 1;
}
}
final class Child extends Parent
{
public function methodWithDefaultImplementation(): int
{
return 2;
}
} ここで、ある時点で親メソッドがそのメソッド名を変更すると想像してみましょう。
abstract class Parent
{
public function methodWithNewImplementation(): int
{
return 1;
}
}の前に #(Override) 属性、それを知る方法はありませんでした Child::methodWithDefaultImplementation() 名前が変更されたメソッドはオーバーライドされなくなり、予期しないバグが発生する可能性があります。
おかげで #(Override) ただし、この属性のおかげで、PHP は何かが間違っていることを認識できるようになりました。 基本的には、「このメソッドが親メソッドをオーバーライドする必要があることはわかっています。変更される場合はお知らせください。」というものです。
#いくつかの考え
この RFC について私が最も印象に残っているのは、それがいかに無関係である可能性があるかということです。 もう一度、静的アナライザーによって判断できるものについての実行時チェックを追加します。
私が過去に行ったすべての議論を繰り返すつもりはありません。そのため、このトピックに関する以前の考えにリンクして、要約したいと思います。「私たちは見逃している」ということです。 PHP の内部には、静的アナライザーの公式仕様、またはファーストパーティの静的アナライザーが付属している必要があります。 なぜ？ なぜなら、より多くのことが可能になり、PHP が大きく前進することになるからです。
とにかく、多くの人がこの RFC について、特に Internals メーリング リストで同じ議論をしようとしたようですが、無駄でした。
私はこの機能を気にしませんが、おそらく自分で使用することはありません (私はこの種の間違いを防ぐ IDE を使用しています。PHP ランタイムで再チェックする必要はありません)。 私が残念に思っているのは、PHP コミュニティが静的解析派と非静的解析派に分かれていることです。そして、言語を統一して静的解析に導くことができる人が現れるかどうかはわかりません。次の10年の進歩。