PHP8.0互換方針

設計は最新、コードは互換

Naifyの考え方は、古いPHPに合わせて設計まで後退させることではありません。コードは8.0で動かしつつ、設計判断は新しいPHPの方向性に寄せます。

PHPアップデート時に採用したい機能の例

アトリビュート戦略

#[NaifyCompatibility]は、将来採用できる書き方をコード上に残すための印です。

互換対応で残しておきたい情報は、PHPDocだけに寄せず#[NaifyCompatibility]アトリビュートでも明示します。そうすると、機械的に集められて、IDEでも追いやすいです。

#[\NaifyCompatibility(php: '8.0', upgrade: ['8.1' => 'readonly'])]
final class Table
{
    // ...
}

#[\NaifyCompatibility(upgrade: ['8.4' => 'property hooks'])]
public function getPrimaryKey(): array
{
    return $this->primaryKey;
}

• 検出できる: Reflectionで機械的に収集できる
• 構造化できる:バージョンと候補をキー付きで持てる
• IDEで追いやすい:検索、参照、ハイライトが効く
• 消し忘れに気づきやすい:バージョンを上げたときの戻し漏れを減らせる

品質と検証

互換方針は、方針だけではなくチェックの仕組みとセットで運用します。NaifyではHTTPテスト、lint、IDEインスペクションを並行して使います。

アップグレード手順

最低動作バージョンを引き上げるときは、互換対応をまとめて洗い出して、新しい構文や機能へ順に置き換えていきます。どこに互換対応があるか見えていれば、PHPアップデートは全面的な読み直しではなく、対象を絞った作業にしやすいです。

1. 互換性チェックで対象を一覧化する
2. ターゲットPHPバージョンごとに採用できる構文を確認する
3. lintとHTTPテストで回帰がないか確認する
4. 不要になったアトリビュートを整理する

コラム:なぜPHP8.0を残すのか

PHP8.0は新しい世代ではありませんが、実運用ではまだ使われている環境があります。共有サーバーや既存案件では、すぐに8.2以降へ上げられない場面も珍しくありません。

Naifyは、小さく始めやすく、置けば動くことを強みにしています。その入口を狭めすぎないために、最低動作はPHP8.0に置いています。

具体例:RHEL9系ではまだ遠い話ではない

たとえば、Red Hat公式の「RHEL 9 Application Streams Life Cycle」では、PHP8.0のretirement dateは2032年5月とされています。Rocky Linux 9のサポート終了は2032年5月31日、AlmaLinux 9も2032年5月31日までセキュリティサポートがあります。

つまり、RHEL9系を前提にした現場では、PHP8.0が「もう存在しない前提」で切り捨てられるとは限りません。Naifyは、その現実を無視せずに入口を広く残しています。