型は「お守り」ではない、設計の「契約」だ：Hack型チェッカーを拡張する静的解析の深淵
Hack言語を単なる「型のあるPHP」だと思っているなら、君の設計はまだ半分しか活かされていない。我々がHHVMと共に作り上げたこの言語は、単にランタイムの安全性を高めるためのものではない。型チェッカー（`hh_client`）こそが、君のチームのアーキテクチャを強制し、バグを未然に消滅させる最強の武器だ。
今日は、標準の型システムという「守り」から一歩踏み出し、カスタムアノテーションと静的解析を駆使して、ビジネスロジック固有の制約をコードに刻み込む「攻め」の設計を伝授する。
—
1. なぜ「標準の型」だけでは足りないのか
例えば、機密情報を扱うシステムで「このメソッドの引数は必ず暗号化されている必要がある」という制約を、通常の `string` 型で表現できるか？ 答えは「No」だ。単なる `string` では、生データと暗号化済みデータが混在し、開発者のミスで平文がデータベースに流出する。
ここで「型チェッカーを拡張する」という発想が必要になる。我々が目指すのは、「ランタイムで例外を投げる」のではなく、「コンパイル時（型チェック時）にビルドを失敗させる」ことだ。
2. カスタムアノテーション（NewType）による制約の強制
Hackの `newtype` は、単なる型の別名ではない。型のカプセル化だ。特定のモジュール内でのみ実態を知り、それ以外の場所では「不透明（opaque）」な存在として扱う。
以下は、平文と暗号文をコンパイルレベルで分離する設計パターンだ。
namespace Security;
// 外部からは中身が不明な「不透明型」として定義
newtype EncryptedString = string;
/
- 厳格に暗号化されたデータのみを受け付ける関数
/
function saveToDatabase(EncryptedString $data): void {
// ここに来る時点では、確実に暗号化済みであることが保証される
print(“Saving: ” . $data);
}
/
- 暗号化ロジック（このモジュール内でのみ、stringから変換を許可）
/
function encrypt(string $plain): EncryptedString {
return (EncryptedString)base64_encode($plain); // 変換を許可
}
// 利用側のコード
function process(): void {
$raw = “sensitive_data”;
// saveToDatabase($raw); // 【型エラー発生！】: string型はEncryptedString型に代入不可
$secure = encrypt($raw);
saveToDatabase($secure); // OK
}
このアプローチの利点は、ランタイムのオーバーヘッドが一切ないことだ。HHVMは実行時にこの型を剥ぎ取り、ネイティブの文字列として扱うため、パフォーマンスを犠牲にせずに「ビジネス上の安全性」を担保できる。
—
3. 「型のリファクタリング」がもたらす保守性の極致
実務の現場では、API連携や非同期処理において「状態」の管理が最大の課題となる。`Pending`, `Processing`, `Completed` といった状態を文字列で管理して `if` 文で分岐させているなら、今すぐやめるべきだ。
`HH\Enum` や `shapes` を活用し、型チェッカーに「状態遷移」を理解させる。
type TJobState = shape(
‘status’ => ‘pending’ | ‘processing’ | ‘completed’,
‘payload’ => string,
);
/
- 状態遷移を型で固定する
- 開発者は、この関数を呼び出す前に「どの状態であるか」を型で証明せねばならない
/
function transitionToProcessing(shape(‘status’ => ‘pending’, …) $job): shape(‘status’ => ‘processing’, …) {
return $job with { ‘status’ => ‘processing’ };
}
このように、関数シグネチャを「許可される状態のサブセット」として定義することで、「まだ処理が終わっていないのに完了後のロジックを呼ぶ」というバグを、IDEの赤波線だけで検知できる。 これが、テストコードを減らし、デバッグ時間を削る「静的解析の真の威力」だ。
—
4. チーフアーキテクトからの助言：パフォーマンスと美学
型チェッカーを拡張する際、注意すべき点が一つある。「型を複雑にしすぎない」ことだ。
HHVMの型チェッカーは強力だが、あまりに深くネストされたジェネリクスや、複雑な形状の結合は、チェック時間を増大させる。コードの美学とは「いかに賢い型を書くか」ではなく、「いかにシンプルな型で、ビジネスの意図を正確に表現するか」にある。
- 型推論を過信しない: 明示的な型定義は、コードのドキュメントだ。
- `mixed` を撲滅する: `mixed` は型安全における敗北宣言だ。どうしても必要な場合以外は、`shape` や `interface` で境界を明確にせよ。
- 型エイリアスを活用する: 長い型定義は `type` エイリアスで名前をつけ、意味を持たせろ。
—
最後に：型は「守り」ではなく「設計図」だ
Hackの型チェッカーを拡張するということは、君自身が「言語の一部」になるということだ。チームメンバーが君の書いたコードを触るたび、型チェッカーが「それは違うぞ」と優しく、しかし厳格に導いてくれる。
コードは書いた瞬間から腐敗が始まる。しかし、型による制約をコードベースの骨格に組み込んでおけば、その腐敗を大幅に遅らせることができる。
さあ、今日から `newtype` を使い倒し、君のコードから「実行時エラー」という概念を過去のものにしてほしい。それが、世界最高峰のエンジニアが歩む道だ。