PHPからHackへ：Strict Modeへの「外科手術」的アプローチ
既存のPHPレガシーを抱えながら、型安全性という聖杯を求める君へ。
多くのエンジニアが「Partialモードで少しずつ型をつければいつかはStrictになる」という幻想を抱く。だが、現実は甘くない。型のないPHPの海に、型安全という名の小島を浮かべても、それは単なる「型による装飾」に過ぎず、HHVMの最適化エンジンであるJIT（Just-In-Time Compiler）の真の恩恵を受けることはできない。
HHVMの真骨頂は、型が確定しているからこそ可能な、メモリレイアウトの最適化にある。今日は、Partialモードの甘えを捨て、Strictという「真の堅牢性」へ至るための戦略的ロードマップを伝授する。
—
1. なぜ「Partial」は「Strict」への通過点ではないのか
Partialモードでは、型チェッカー（HHVM Typechecker）は「未知の型」に対して寛容だ。だが、これが罠だ。`mixed`や曖昧な型推論を許容する限り、コンパイラは動的なディスパッチを諦めざるを得ない。
Strictへの移行は、「コードを書き換える」のではなく「境界（Boundary）を定義する」作業である。
戦略的ステップ：
1. 境界の隔離: 外部入力を受け取るクラス（コントローラーやゲートウェイ）を先にStrict化する。
2. Nullableの撲滅: `?T`という逃げ道を使わず、デフォルト値または`Shapes`による明示的な構造定義へ移行する。
3. Genericsの徹底: 型を動的に扱う箇所を、ジェネリクスによって「コンパイル時に確定する型」へと変換する。
—
2. 実践的コード例：動的配列からShapesへの昇華
PHP開発者がやりがちな「連想配列」の乱用。これを放置してStrict化は不可能だ。以下のコードを見てほしい。
悪い例（Partialで放置されたコード）
// 外部からの入力をそのまま扱う危険なコード
function processData(mixed $data): void {
// 型が不明なため、実行時にエラーが起きるリスクがある
echo $data[‘user_id’];
}
改善例（Strict Modeでの堅牢な定義）
`type`または`shape`を定義し、データの契約（Contract）を強制する。
<<__Strict>>
namespace App\Domain;
// データの構造を厳格に定義
type UserProfile = shape(
‘id’ => int,
‘name’ => string,
‘email’ => string,
‘is_active’ => bool,
);
final class UserProcessor {
/
- 外部境界で型を確定させる。
- DictをShapeにキャストすることで、ここから先は型安全が保証される。
/
public function process(dict
// 構造のバリデーションを通過した瞬間、型が確定する
return shape(
‘id’ => (int)$raw_data[‘id’],
‘name’ => (string)$raw_data[‘name’],
‘email’ => (string)$raw_data[‘email’],
‘is_active’ => (bool)($raw_data[‘is_active’] ?? false),
);
}
}
—
3. パフォーマンスへの影響：なぜStrictが必要か
HackのStrict Modeで書かれたコードは、HHVMのJITエンジンにおいて「型ガード（Type Guards）」を必要としない命令セットに変換される確率が飛躍的に高まる。
- Partialモード: コードの随所で「この変数は本当にintか？」という実行時チェック（Type Check）が走る。
- Strictモード: コンパイラは型が確定していることを信頼するため、チェックを省略し、直接CPUレジスタへ値をロードする最適化を施す。
君がStrictにこだわる理由は、コードの清潔さだけではない。「CPUに対する命令の無駄を削ぎ落とす」というパフォーマンス上の最適化でもあるのだ。
—
4. 現場ですぐ使える「安全な移行」の鉄則
移行作業で最も重要なのは「リファクタリングを止めない」ことだ。以下の3点を守れ。
1. `mixed` を撲滅する: `mixed`が残っている場所は、型チェッカーの盲点だ。`TypeAssert`ライブラリなどを使い、境界で必ず具体的な型に落とし込む。
2. `newtype` を活用せよ: プリミティブな`int`や`string`をそのまま使い回すな。`newtype UserId = int;`のように抽象化することで、型の意図が明確になり、バグの温床となる「型は同じだが意味が違う値の混入」を防げる。
3. HHVMのプロファイラを信じろ: 移行の過程でパフォーマンスが落ちるようなら、それは型設計が複雑すぎる証拠だ。再帰的な型定義や、複雑なShapeのネストは避け、シンプルでフラットな構造を保て。
—
結論：型は「制約」ではなく「武器」である
Strict Modeへの移行は、単なる規約の押し付けではない。それは、君が書くコードに「実行時に発生するエラーを、ビルド時に発見する」という最強の盾を持たせることだ。
リファクタリングに恐怖を感じる必要はない。HHVMの型チェッカーは、君がコードを壊そうとした瞬間に悲鳴を上げてくれる。その警告こそが、君のプロダクトを伝説的な品質へと昇華させるための道標となる。
さあ、エディタを開き、最初のファイルを `<<__Strict>>` で書き換えてみろ。コンパイラが君のコードを最適化しようと待ち構えている。