虚像のGenericsを捨てよ：Hack `reified` がもたらす「型安全な実行時」の深淵
Hack言語の型システムにおいて、多くのエンジニアが陥る罠がある。それは「Genericsはコンパイル時に消去される（Type Erasure）」というPHP由来のメンタルモデルを、そのままHackに持ち込んでしまうことだ。
通常のGenericsにおいて、実行時の型情報は消滅する。`vec
ここで登場するのが `reified` 型パラメータだ。これは単なる糖衣構文ではない。HHVMの仮想マシンレベルで型情報を保持し、実行時にその「実体」を突きつけるための強力な武器だ。
1. なぜ `reified` なのか？ ― 型の正体を暴く
通常、Genericsはコンパイル時に型整合性をチェックし、実行時は単なる「値の集合」として扱われる。しかし、`reified` を宣言すると、HHVMは実行時までその型情報を維持する。
以下のコードを見てほしい。通常のGenericsでは決して実現できない「実行時の型照合」だ。
<<__EntryPoint>>
async function main(): Awaitable
// 実行時に型を確認するクラス
$validator = new TypeValidator
// 実行時にTがintであることを検知できる
var_dump($validator->isType(10)); // bool(true)
var_dump($validator->isType(“10”)); // bool(false)
}
class TypeValidator
public function isType(mixed $value): bool {
// reifiedのおかげで、Tの情報が実行時に利用可能
return $value is T;
}
}
この `isType()` の中にある `is T` という記述。これはHackのランタイムが、`reified` によって付与された型タグを動的に走査していることを意味する。
2. 実務での最強パターン：型安全なデータマッピング
APIから受け取った `dict
abstract class APIResponseConverter {
/
- reified T を使うことで、デシリアライズ先を明確に制御できる
/
public static function map
// 実行時に T が期待されるクラス構造を持っているか、あるいは
// 型安全な制約を満たしているかを検証する
if (!(is_subclass_of(T::class, ‘SerializableEntity’))) {
throw new InvalidArgumentException(“T must be a SerializableEntity”);
}
// 実際の実務ではここから hydrate 処理へ繋ぐ
return / … 変換ロジック … / ;
}
}
パフォーマンスへの注意点
「実行時に型検査をするなら遅いのでは？」という懸念はもっともだ。しかし、HHVMのJITコンパイラは `reified` 型パラメータを最適化された命令セットにインライン展開する。リフレクションライブラリを自前で実装して文字列比較を繰り返すよりも、遥かに高速かつメモリ効率が良い。
3. アーキテクトからの忠告：`reified` を使うべき境界線
すべての型に `reified` を付けるのは悪手だ。それは「コードの複雑性」という負債を増やすだけである。以下の基準で採用を判断せよ。
- 採用すべきケース:
- 外部からの入力を受ける「境界層（Boundary Layer）」
- DIコンテナやファクトリパターンなど、型に基づいてインスタンスを動的に生成・検証する箇所
- コレクションのフィルタリングで、実行時に厳密な型判定が必要な場合
- 避けるべきケース:
- 計算ロジックやドメインモデルの深部（静的解析だけで十分な場所）
- 頻繁に呼び出される再帰構造（コンパイルコストと実行時の型タグ追跡コストが増大する）
結論：型を「コード」から「信頼」へ
Hackの `reified` は、型システムを単なる「コンパイル時のチェックリスト」から「実行時にも寄り添う守護者」へと昇華させる。
プロダクション環境でバグを減らす唯一の道は、「実行時の確信」をコンパイラに委ねることだ。コードレビューにおいて、もし型検査のために `is_a()` や `get_class()` を乱用している箇所を見つけたら、即座に `reified` へのリファクタリングを提案せよ。
それが、HHVMという強靭なエンジンを使いこなす、真のHackエンジニアの矜持である。