Nullable汚染を断つ：型チェッカーを「防波堤」に変えるアーキテクチャ設計術
Hackの型システムにおいて、`?T`（Nullable）という型は諸刃の剣だ。
多くの開発者が「値が存在しない可能性があるならNullableにすれば良い」と安易に型定義を行うが、それはアーキテクチャの敗北を意味する。`?T`がコードベース全体に伝播した瞬間、至る所で`if ($obj !== null)`というボイラープレートが蔓延し、HHVMの型推論器（HackC/HHBC）がその背後で無駄なブランチ予測を繰り返すことになる。
真のシステムアーキテクトは、Nullableを「避ける」のではなく、型チェッカーを「防波堤」として使い、ドメイン境界でNullableを消滅させる設計を好む。
—
1. 「Nullableの伝播」はなぜ悪か：JITとメモリの視点から
`?T`を多用すると、HHVMのJITコンパイラは型ガードの挿入を余儀なくされる。これは単なるコードの冗長化ではない。
- レジスタ割り当ての制約: Nullableな型は、内部表現においてユニオン型（タグ付き共用体）として扱われるケースが多い。JITが最適化する際、タグのチェックが頻発することで、CPUのパイプライン効率が低下する。
- 型推論の複雑化: `Strict Mode`下において、`?T`が関数を跨いで伝播すると、型チェッカー（`hh_client`）は呼び出し先での検証を強制される。これはコンパイル時間だけでなく、型推論の境界を曖昧にし、思わぬ型エラーの温床となる。
2. 「Nullableの遮断」：境界型（Boundary Types）の導入
Nullableをコードの奥深くまで引きずり込むな。代わりに、ドメイン境界において「完全な状態」を保証する型を定義せよ。
例えば、ユーザーのプロフィール取得において、DBのnullをそのまま返すのではなく、`Profile`クラスそのものを「Null Object」として扱うか、あるいは初期化済みであることを保証するラッパーを使用する。
不適切な設計（Nullableの連鎖）
// どこでnullチェックをすべきか不明確になり、責務が拡散する
function get_display_name(?User $user): string {
if ($user === null) return ‘Guest’;
return $user->getName();
}
改善された設計（境界での確定）
// 「未ログイン」という状態を明確な型で分離する
abstract class UserState {}
final class Guest extends UserState {}
final class Authenticated extends UserState {
public function __construct(public User $user) {}
}
// 呼び出し側で一度だけパターンマッチを行い、ロジック内では常に非nullを保証
function render(UserState $state): string {
return match($state) {
is Guest => ‘Guest’,
is Authenticated => $state->user->getName(),
};
}
—
3. 型チェッカーをハックする：`Shapes`と`Refined Types`の活用
複雑なデータ構造を扱う際、`shape`をそのままNullableで渡すのは最悪のプラクティスだ。Hackの`Shapes::idx`を安易に使う前に、`Shapes::keyExists`や`Shapes::removeKey`を用いて、型チェッカーに「データが揃っていること」を証明させる。
type TUserShape = shape(‘id’ => int, ‘email’ => string);
function process_user(shape(‘id’ => int) $partial): void {
// コンパイル時にこのshapeがidを持つことは保証されている
// 不要なnullチェックは排除される
$id = $partial[‘id’];
}
4. HHVMの最適化を信じろ：プロファイリングの極意
我々コアチームがHHVMに実装しているのは、型の「厳密さ」がパフォーマンスに直結する仕組みだ。`Strict Mode`で記述されたコードは、型が保証されている範囲で、JITが型チェックコードを大胆に削除（Dead Code Elimination）できる。
- `readonly`プロパティの活用: `?T`を減らすために、コンストラクタで初期化を完了させ、`readonly`属性を付与せよ。これにより、メモリレイアウトの最適化が図られ、ランタイム時の属性読み取りが高速化される。
- `invariant`の戦略的利用: どうしてもNullableを排除できない境界線では、`invariant($obj !== null, ‘Should be initialized’);` を使用せよ。これは単なるアサーションではなく、型チェッカーに対して「この先は絶対にnullではない」という強いヒントを与える。
結び：防御的プログラミングの先へ
Hackにおける真のクリーンコードとは、型チェッカーを「エラーを指摘するだけの監視者」ではなく、「推論エンジンを最適化するための強力な味方」として使いこなすことにある。
`?T`を見た瞬間に思考停止して`if`で囲うのではなく、「なぜここでnullが発生しうるのか？」「どの境界でその曖昧さを殺すべきか？」を問うてほしい。
型システムは、あなたのコードの守護神だ。その守護神が最大限の力を発揮できるよう、Nullableの伝播を遮断し、論理的な境界を明確にせよ。それが、HHVMの真の性能を引き出し、堅牢なシステムを構築するための唯一の道である。
—
Hackコアコミッターとして、常にコードの「背後にある計算機」を感じろ。型はただの記号ではない。それはメモリの配置であり、CPUの分岐であり、あなたのシステムの生存確率そのものなのだ。