Nullable汚染を断て：HHVM型チェッカーを味方につける堅牢な設計戦略
Hackの型チェッカー（`hh_client`）と対峙しているとき、君は「型システムの警告」を単なる邪魔者だと思っていないか？
もし、至る所で `?T` (Nullable) が氾濫し、コードの随所に `is` チェックや `??`（null合体演算子）が散らばっているなら、それは設計の敗北だ。HHVMの静的解析エンジンは、単にエラーを吐くツールではない。君のコードの「曖昧さ」を容赦なく暴く、最も厳格なレビューアーだ。
今日は、Nullable型がシステム全体を汚染するのを防ぎ、型エラーを局所化して「壊れないコード」を構築するための極意を伝授する。
—
1. なぜ「Nullable汚染」は悪夢なのか
Nullable型が伝播するということは、その変数が「有効な値」と「状態の欠如（null）」の二つの意味を同時に持ち歩いていることを意味する。
これを受け取った関数は、本来のドメインロジックに加え、「もしnullだったら」という分岐処理を強制される。これが連鎖すると、ビジネスロジックがnullハンドリングというノイズで埋め尽くされ、バグの温床となる。
「nullを許容する場所」をインターフェースの境界線（APIレスポンスやDB読み込み）に限定し、ロジックの中核には常に「純粋な型」を流す。 これがアーキテクトの鉄則だ。
—
2. 実践：Nullable伝播を最小化する設計パターン
アンチパターン：nullを内部まで持ち込む
// 悪い例: nullがそのままビジネスロジックに侵入している
function processUser(?User $user): void {
if ($user !== null) {
// ここにロジックが書かれるが、この関数自体がUser不在の状態を管理している
$this->updateStatus($user);
}
}
推奨パターン：境界で正規化し、ロジックは非Nullableで書く
境界線（Boundary）で型を確定させる「Type Guard」のパターンを使え。
<<__ConsistentConstruct>>
final class UserProcessor {
// 外部からの入力はNullableで受け入れる
public function execute(?User $user): void {
// 1. 早期リターンでnullの可能性を排除する（局所化）
if ($user === null) {
return;
}
// 2. ここからは $user は確実に User 型として扱われる
$this->processStrict($user);
}
// 3. ロジック本体は非Nullableで記述する
private function processStrict(User $user): void {
// ここには null チェックは一切不要。
// 型チェッカーは $user を確実に User と認識し、最適化されたコードを生成する
echo $user->getId();
}
}
—
3. 型チェッカーを制御する高度なテクニック
`Shapes::idx` の罠と `Shapes::at` の使い分け
`shape` を扱う際、漫然と `Shapes::idx` を使っていないか？ `idx` はデフォルトで `?T` を返す。これこそがNullable汚染の第一歩だ。
必須項目であれば、迷わず `Shapes::at` を使え。
type UserData = shape(‘id’ => int, ‘name’ => string);
function handle(UserData $data): void {
// Shapes::at はキーが存在しない場合、KeyNotFoundExceptionを投げる
// 予期せぬ欠損を型チェックだけでなくランタイムでも即座に潰す
$id = Shapes::at($data, ‘id’);
}
`invariant` によるアサーションの活用
コードの深い場所で「ここには絶対にnullは来ない」と確信がある場合、`invariant` を使え。これは単なるチェックではなく、HHVMの静的解析エンジンに対して「ここからはこの型である」という強いヒントを与える。
function updateAccount(Account $account): void {
$profile = $account->getProfile();
// ここで型チェッカーは $profile を ?Profile と認識している
invariant($profile !== null, ‘Profile must be initialized for active accounts’);
// この行以降、型チェッカーは $profile を Profile 型として扱う
$profile->updateLastLogin();
}
—
4. パフォーマンスの視点：型エラーを回避することは「最適化」である
HHVM（HipHop Virtual Machine）は、型が固定されているほどJITコンパイルの精度が向上する。
Nullable型が多用されると、HHVMのランタイムは実行時に「この値はnullか？」というチェック（Type Guard）を動的に繰り返さざるを得ない。一方で、型が確定していれば、JITコンパイラは型チェックのオーバーヘッドを排除し、直接的なCPU命令へと変換できる。
「型エラーを減らすこと」は、保守性を高めるだけでなく、実行速度を劇的に改善するチューニングそのものだ。
—
まとめ：アーキテクトからの提言
1. 境界線以外で `?` を使うな。 データの入り口でnullを処理し、内部ロジックは常にクリーンな型で戦え。
2. `invariant` は思考の補助線ではない。 堅牢な契約（Design by Contract）としてコードの随所に埋め込め。
3. 型チェッカーを「敵」と思うな。 それは君が書いたコードの論理的な脆弱性を、実行前に警告してくれる唯一の味方だ。
Hackのパワーを最大限に引き出すのは、言語仕様ではなく、君の設計思想だ。Nullableを制する者が、大規模なHHVMプロジェクトの安定性を制する。
さあ、エディタを開いて、その汚染されたコードをリファクタリングする時間だ。迷わず行け。