【テクニカル・上級編】Hackの『Shapes』型における構造的部分型と名前付き型の境界線：設計時に迷わないための使い分け基準 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Shapesの境界線：構造的柔軟性と名前付き型のドメイン制約を掌握する

HHVMのランタイムにおいて、`shape`は単なる連想配列のラッパーではない。それは、コンパイル時に静的解析され、JITコンパイルの過程で効率的なデータ構造へと昇華される「型付きのデータレイアウト」だ。

多くの開発者が、`shape`の持つ「構造的部分型（Structural Subtyping）」の誘惑に負け、ドメインモデルを崩壊させている。今日は、HHVMの深淵からこの設計のアンチパターンを解剖し、真に堅牢なシステムを構築するための境界線を提示する。

—

1. 構造的部分型の「罠」とメモリ最適化の真実

Hackにおける`shape`は、構造的に合致していれば型互換性があると見なされる。この柔軟性は、外部APIのデータ転送や一時的なデータ変換には極めて有用だ。しかし、これをビジネスロジックの核となるエンティティに適用するのは、型システムの意図を放棄するに等しい。

なぜ構造的型付けは「防弾」ではないのか

構造的部分型は、「型」ではなく「形」を見ている。HHVMの型チェッカー（`hh_client`）は、その形状が一致している限り、それが「ユーザー」を表しているのか「プロダクト」を表しているのかを区別しない。

type TUser = shape(‘id’ => int, ‘name’ => string);
type TProduct = shape(‘id’ => int, ‘name’ => string);

function process(TUser $u): void { / … / }

// 構造が同じであれば、TProductを渡してもコンパイルエラーにはならない
// これはランタイムエラーの温床となり、型安全性の霧散を招く
function invoke(TProduct $p): void {
process($p); // コンパイラは黙認する
}

この挙動は、HHVMのJITエンジンが生成するマシンコードレベルでは、単なるオフセットアクセスとして処理される。つまり、メモリレイアウトが同じであれば区別はつかない。この「区別がつかないこと」が、複雑なシステムにおけるバグの温床となるのだ。

—

2. 名前付き型（Named Types）による「領域の封じ込め」

ドメインモデリングにおける鉄則は、「意味の異なるデータは、物理的な型で分離せよ」である。これをHackで実現するには、`newtype`（opaque type alias）を活用し、構造的部分型の恩恵を抑制しなければならない。

`newtype`によるカプセル化

`newtype`を定義することで、モジュール外からはその内部構造を隠蔽し、型チェッカーに「これは他とは異なる型である」と強制的に認識させることができる。

// User.hhi
// 外部からは内部構造が見えないため、構造的互換性は無効化される
newtype UserID = int;

// 内部モジュール内でのみ実装を共有する
function createUserID(int $id): UserID {
return $id;
}

これにより、構造が一致していても、型レベルで厳格に弾かれるようになる。これはHHVMのJIT最適化を阻害することなく、コンパイル時の安全性だけを向上させる、極めてコストパフォーマンスの高い設計手法だ。

—

3. 実務的設計基準：どちらを選ぶべきか

設計時に迷った時は、以下の基準を「型チェッカー」として脳内にインストールしてほしい。

境界線の引き方：リファクタリングの指針

1. 外部境界（APIエンドポイントなど）： JSONペイロードをデコードする段階では、柔軟性の高い `shape` を受け入れる。
2. 変換層（Mapper）： `shape` を受け取り、直ちにドメインモデル（`class` や `newtype` でラップされた型）へ変換する。
3. ドメイン層： ここからは `shape` を徹底的に排除する。ビジネスルールは型安全な名前付き型の上で記述する。

—

結論：型は「制約」ではなく「設計図」である

HHVMの静的解析能力を最大限に引き出すということは、コンパイラに対して「何を許し、何を許さないか」を極限まで明確に言語化することに他ならない。

`shape`は強力だが、それは「一時的な形」を扱うためのツールだ。ドメインモデルという名の「永続的な意志」を記述する場所ではない。名前付き型を用いてドメインの境界を定義し、システム全体に静的なガードレールを敷き詰めること。それが、大規模なHackコードベースを長年維持し続ける、我々コア開発者の流儀である。

コードが複雑になることを恐れるな。真に恐れるべきは、ランタイムの闇の中で「形状」だけを頼りに誤った処理が実行されることだ。その曖昧さを殺すことが、エンジニアリングの第一歩となる。