型定数（Type Constants）による静的依存解決：HHVMランタイムの深淵から
Hackの `strict` モードは、単なるシンタックスの制約ではない。それは、HHVMのJITコンパイラが実行時に最適化を行うための「事前証明」である。多くの開発者がDIコンテナをランタイムの文字列検索（`service_locator`のような）で解決している中、我々は型システムをハックし、コンパイル時に依存関係を確定させるべきだ。
本稿では、`Type Constants` を用いた依存解決の極致を解説する。これは単なる抽象化ではない。HHVMの仮想関数テーブル（vtable）の解決コストを型レベルで静的に埋め込む、アーキテクチャの最適化手法である。
—
1. なぜ「型定数」なのか：ランタイム・オーバーヘッドの排除
一般的なDIコンテナは、`get(string $id)` というシグネチャを持ち、内部で `instanceof` や動的な生成を行う。これはHHVMにおいて、実行時のハッシュマップ探索と型チェックを強いる。
`Type Constants` をインターフェースに組み込むことで、依存関係の定義を「クラスの型構造」の一部としてコンパイラに認識させることができる。これにより、型チェッカーは具象クラスをインスタンス化する前に、依存グラフの整合性を静的に検証可能となる。
2. 実装：型定数によるDIプロトコル
以下のコードは、型定数 `TService` を用いて、依存対象の型を契約として強制するパターンだ。
<<__ConsistentConstruct>>
interface IServiceContainer {
// 型定数：このコンテナが提供するサービスの型を定義
abstract const type TService as mixed;
public function get(): this::TService;
}
interface IRepository {
public function fetch(int $id): string;
}
// 具象実装
final class UserRepository implements IRepository {
public function fetch(int $id): string {
return “UserEntity:{$id}”;
}
}
// 型安全なコンテナ
final class UserContainer implements IServiceContainer {
// 型定数を具象クラスで固定
const type TService = IRepository;
public function get(): this::TService {
return new UserRepository();
}
}
3. HHVMの内部挙動：JITの最適化視点
この設計の肝は、`this::TService` という参照にある。HHVMのJITコンパイラは、`strict` モード下において、この型定数が指し示す先が静的に解決可能であると判断した場合、インライン展開（Inlining）の対象候補として最適化を加速させる。
- vtableの短縮: 実行時の型検査が不要になるため、メソッド呼び出し時のガードチェックを最小化できる。
- メモリの局所性: 依存する型がコンパイル時に決定しているため、HHVMはオブジェクトのレイアウトを最適化し、キャッシュミスを低減させるメモリ配置を生成する。
4. 限界への挑戦：複雑なDIグラフの静的検証
複数の依存関係を持つ場合、型定数をネストさせることで、依存グラフを型空間に展開できる。
interface ILogger { public function log(string $msg): void; }
interface IApplication {
abstract const type TLogger as ILogger;
abstract const type TRepo as IRepository;
public function run(): void;
}
// 依存関係を型レベルで結合
final class WebApp implements IApplication {
const type TLogger = FileLogger;
const type TRepo = UserRepository;
public function run(): void {
// コンパイラはここで TLogger, TRepo がそれぞれ
// ILogger, IRepository を満たすことを保証する
$logger = new (this::TLogger)();
$repo = new (this::TRepo)();
}
}
5. アーキテクトの戒め：セキュリティとパフォーマンス
この手法を導入する際、注意すべき点が二つある。
1. 具象クラスの不変性: `type` を `as` で制約することで、DIのすり替え攻撃（不正な型へのキャスト）を防ぐ。これはメモリ安全性を担保する最後の砦である。
2. 再帰的な型解決のコスト: 巨大なDIグラフを構築すると、型チェッカーの推論深度が限界に達し、`hh_client` のオーバーヘッドが増大する。型定数は「ビジネスロジックの境界」で利用し、過度な抽象化は避けるべきだ。
結論
Hackの `Type Constants` は、単なる糖衣構文ではない。これは、実行時に行われていた「型解決」というコストを、コンパイルという安全な領域へと引き剥がすための強力なツールである。
我々ランタイムエンジニアの責務は、システムを動かすことではなく、システムが「存在しうる状態」を極限まで絞り込み、HHVMが最大限の速度でコードを実行できる環境を整えることにある。静的型付けとは、すなわち「未来の実行エラーを現在の型エラーに置換する」という、最も効率的なセキュリティ・エンジニアリングなのである。
コードを型で縛れ。さもなくば、ランタイムに裏切られることになるだろう。