(jp) =
おそらく、プログラミングのキャリアのある時点でそれらに対処したことがあります。
Deprecated: Creation of dynamic property Post::$name
is deprecated in /in/4IreV on line 10非推奨の通知
それらは多くの開発者にとって煩わしくイライラするものですが、実際には目的を果たしています。 彼らの目標と対処方法を理解すれば、彼らに感謝するでしょう。 見てみましょう！
ところで、このブログ投稿を vlog としてご覧になることもできます。
# 1. 非推奨は役に立つ
「私の PHP スクリプトがマイナー バージョンの更新で壊れるのはなぜですか??」というのはよくある不満です。 まさにそのとおりです。PHP は、マイナー リリースに非推奨の通知を追加する傾向があり、プロジェクトのアップグレード時に聞こえる傾向があります。 たとえば PHP 8.1 では、突然ログが次のような警告でいっぱいになりました。
Return type should either be compatible with
IteratorAggregate::getIterator(): Traversable,
or the #[ReturnTypeWillChange] attribute should be used
to temporarily suppress the notice非推奨とは何かを理解することが重要です。それらはエラーではなく、 注意事項. これらは、将来の重大な変更について PHP 開発者に通知する方法です。 彼らはあなたに前もって警告し、差し迫った重大な変更に対処するための十分な時間を与えたいと考えています.
もちろん、これらの重大な変更や派手な機能が本当に必要なのかという質問もあるでしょう。 私たちは 本当 次のような内部戻り値の型を変更する必要があります IteratorAggregate::getIterator(): Traversable、私たちは 本当 動的プロパティを禁止する必要がありますか?
私の意見では — PHP 内部開発者の大半が共有していることですが — はい。 PHP は改善し続ける必要があり、さらに成長する必要があります。 そしてそれは、例えば内部が組み込みクラスメソッドに戻り値の型を追加するときのように、重大な変更を導入することを意味する場合があります: IteratorAggregate ユーザーランド コードでは、いくつかの変更を加える必要があります。 言語は進化する必要があります。
全体として、このように進化する言語に伴ういくつかの煩わしさにもかかわらず、それは良い方向に進んでいると言えます。
幸いなことに、非推奨通知のようなメカニズムがあります。これらは、将来何かが壊れる可能性があるが、現在でも使用できることを示しています。 コードベースの周りに段階的に変更や更新を加えることができます。
# 2. 非推奨は黙らせることができる
第二に、PHP の内部構造は、ユーザーランドの開発者が非推奨に対処するのを助けるために多大な努力を払っています。 PHP 8.0 で属性が追加されたおかげで、コードと PHP のインタープリターとの間の通信方法が大幅に改善され、標準化されました。
例：ユーザーランドコードにタグを付けることができます ReturnTypeWillChange 非推奨の通知が表示されないようにするための属性。
final class MyIterator implements \IteratorAggregate
public function getIterator()
もちろん、このコードは PHP 9.0 で壊れます。 次のメジャー バージョンにアップグレードする場合は、これらを修正する必要があります。
final class MyIterator implements \IteratorAggregate
public function getIterator(): \Traversable
もう1つの例でしょうか？ PHP 8.2 で動的プロパティが非推奨になったため、クラスを次のようにマークできます。 AllowDynamicProperties 属性を変更して、動的プロパティを再度許可し、非推奨通知を抑制するようにします。
class Post
$post->title = 'Name';# 3. それらは通知であり、致命的なエラーではありません
PHP コードは、その一部が非推奨通知をトリガーした場合でも、問題なく動作し続けます。 もちろん、次のメジャー バージョンにアップグレードする必要がある場合は、それらを修正することが最善であることはすでにわかっていますが、今すぐに修正する必要はありません。 運用プロジェクトをアップグレードし、時間の経過とともに非推奨の通知に対処することはまったく問題ありません。
本番環境では非推奨通知を完全に無効にするか、少なくともエンド ユーザーに表示しないことをお勧めします。
error_reporting(E_ALL ^ E_DEPRECATED);おそらく、最初の数か月間は外部エラートラッカーを使用してそれらを追跡し、それらの非推奨を修正する必要がある場所の明確なイメージを得ることができます. しかし何よりも、PHP の最新のマイナー バージョンにアップグレードする際に、非推奨の通知が妨げになるべきではありません。
# 4. 自動化
最後に、退屈な作業を手動で行う必要はないことを覚えておいてください。 多くのアップグレードの問題を処理できる Rector や phpcs などのツールがあります。 通常、コードベースをスキャンして修正するには、せいぜい数分かかるスクリプトを実行するだけです。 手作業だと何日もかかる作業です。
PHP のアップグレードに対処することは、もはや難しくなく、時間もかかりません。 実際、非推奨は、よりスムーズなアップグレード パスを作成し、将来に向けてコードベースを準備するのに非常に役立ちます。
私は非推奨が好きです、あなたもそうすべきです。
//platform.twitter.com/widgets.js