混沌からの脱却：Hack Strict Modeへの漸進的移行と型安全性の深淵
Hack言語のコアエンジンの深層に触れるとき、我々が直面するのは「PHPの動的な自由度」と「静的型の厳格な規律」の間の終わりのない衝突だ。大規模コードベースにおける `Partial` から `Strict` への移行は、単なるリファクタリングではない。それはHHVMのJITコンパイラに対して、実行時の型推論という「推測」を捨てさせ、確定的なメモリレイアウトを要求する「契約」の締結に他ならない。
本稿では、レガシーな `Partial` コードの海を、いかにして安全に、かつHHVMの最適化性能を最大化する `Strict` の聖域へと導くか。その極限の戦略を解剖する。
—
1. 境界線上の罠：Partial/Strict 混在環境のトポロジー
`Partial` モードが抱える最大の技術的負債は、「型チェックの穴（Type Hole）」だ。`Partial` ファイルから `Strict` ファイルへデータが渡る際、型チェッカー（hh_client）は境界で「疑わしい型」を許容せざるを得ない。
ここで重要なのは、HHVMのランタイムがどう振る舞うかだ。
HHVMは、`Strict` コード内で型が確定していると判断すれば、即座にJITを通じてレジスタ最適化を行う。しかし、`Partial` 由来の変数には依然として `Mixed` の影がつきまとう。
移行の第一歩：境界を「厳格な防壁」で囲む
最も危険なのは、`Partial` からの入力を無防備に受け入れることだ。我々はこれを「Type-Safe Gateway」として管理する。
// Partialなレガシーコードから送られてくる不確かなデータ
function get_legacy_data(): mixed {
return dict[‘id’ => 101, ‘name’ => ‘LegacyEntity’];
}
// 境界線（Gateway）での厳格な型変換
final class EntityConverter {
public static function toStrict(mixed $input): MyEntity {
// 実行時に型を強制的に確定させる
if (!($input is KeyedContainer<_, _>)) {
throw new InvariantException(“Data structure integrity violation”);
}
// ここでShapes::idx等を用いて型を絞り込む
return new MyEntity($input[‘id’] as int, $input[‘name’] as string);
}
}
この「境界での強制的な型絞り込み（Refinement）」こそが、`Strict` 移行における最初の防壁となる。HHVMはここを通過した後のオブジェクトに対して、確実な型情報を保持し、メソッド呼び出しを高速な静的ディスパッチへと昇格させる。
—
2. JITコンパイラの視点：最適化を阻害する「型推論の揺らぎ」
HHVMのJITエンジンは、実行時のプロファイル情報（PGO: Profile-Guided Optimization）を活用する。しかし、`Partial` モードのコードが混在すると、JITは「この変数の型はいつか変わるかもしれない」という疑念を捨てられず、デオプティマイズ（最適化の解除）を引き起こす。
構造的データのメモリレイアウトを固定せよ
移行期において最も避けるべきは、配列（`darray` / `varray`）の乱用だ。これらはランタイムでハッシュテーブルとして扱われ、メモリ効率が極めて悪い。`Strict` への移行とは、これらを `Shape` や `Record`、あるいは `Class` に置き換え、メモリ上のオフセットを固定することである。
// 悪い例：Partial環境で多用される動的配列
type TData = dict
// 良い例：Strict移行後の構造定義
readonly class UserProfile {
public function __construct(
public int $uid,
public string $username,
) {}
}
この変換を行うだけで、HHVMのメモリマネージャ（GC）は配列のハッシュ検索をスキップし、固定長構造体としてメモリを確保できる。これはキャッシュヒット率を劇的に向上させる。
—
3. 型チェッカーの警告管理：段階的移行の極意
`hh_client` の警告をすべて消し去ろうと焦るあまり、本質を見失う開発者が多い。移行は以下の戦略で行うべきだ。
1. 「Strict-Enabled」の伝播: 境界となるクラスをまず `Strict` にし、その依存関係を末端から根へと変換する。
2. `HH\FIXME` の最小化: 警告を無視するのではなく、`as` 演算子による実行時型チェックを挟むことで、`FIXME` を「正当な契約」へと書き換える。
3. `__Soft` 属性の活用: 一時的に警告を抑えるのではなく、型安全性を維持しつつもランタイムのクラッシュを防ぐために、あえて `soft` 型（実行時に例外を投げずログ出力のみにする）を限定的に使う戦略もあるが、これは最終的な Strict 化の過程で必ず除去しなければならない「期限付き負債」と定義せよ。
—
チーフアーキテクトからの提言
Hackにおける `Strict` モードへの移行は、単なるコンパイルエラーの解消ではない。それは、「HHVMという巨大な機械に対して、君のコードがどのようなメモリ構造を持ち、どのような型を保証するかを宣言する、極めて高度なコミュニケーション」である。
`Partial` から `Strict` へ。この道のりは一見すると泥臭い作業に見えるかもしれない。しかし、型チェッカーが沈黙し、HHVMが最適化の極致を体現するようになったとき、君が手にするのは、静的解析によって証明された「壊れないシステム」という究極の平穏だ。
コードを型で縛るのではない。型によってコードの論理構造を宇宙の物理法則のように不変にするのだ。さあ、型チェックを通せ。HHVMを沈黙させるほどに、深く、厳格に。