Hackの『Shape』型における構造的部分型（Structural Typing）の落とし穴：名前付き型との使い分け戦略
HHVM（HipHop Virtual Machine）のコアエンジニアリングにおいて、型システムは単なるコンパイル時の気休めではない。それはランタイムの最適化境界であり、メモリレイアウトを決定づけるハードウェアに近い契約である。
Hack言語の `Shapes` は、アドホックなデータ構造を扱う上で極めて強力なプリミティブだ。しかし、その柔軟性の裏側には、構造的部分型（Structural Subtyping）に起因する深刻な型安全性の落とし穴が潜んでいる。本稿では、HHVMの型チェッカー（hhvm）の内部挙動とメモリ管理の観点から、Shape型と名前付き型（Class / Record）の境界線を再定義し、大規模システムを破綻させないための設計指針を提示する。
—
1. Shapeの正体：型チェッカーの視点とランタイム表現
まず、Hackの `shape(…)` がHHVMの内部でどう扱われているかを理解しなければならない。
PHPの連想配列（Array）の動的なオーバーヘッドを排除しつつ、固定されたキーを持つマップを表現するため、HackのShapeはコンパイル時に厳密なキーの存在と値の型を検証される。しかし、ランタイム（bytecode層）において、Shapeは実質的に通常のPHPアソシエィティブ・アレイ（HT：Hash Table）として表現される。
ここで重要なのは、構造的部分型（Structural Subtyping）のルールが静的にのみ適用され、ランタイムには動的な型タグが消去されるという事実だ。
構造的部分型の罠：余剰プロセスの黙認
以下のコードを見てほしい。Strictモード（` float, ‘y’ => float);
type Point3D = shape(‘x’ => float, ‘y’ => float, ‘z’ => float);
function process_point(Point2D $p): void {
// 2次元としての処理
echo “X: {$p[‘x’]}, Y: {$p[‘y’]}\n”;
}
<<__EntryPoint>>
function main(): void {
// 3次元データを2次元の関数に渡す
// 構造的部分型により、Point3DはPoint2Dの部分型とみなされ、静的チェックを通過する
Point3D $p3 = shape(‘x’ => 10.0, ‘y’ => 20.0, ‘z’ => 30.0);
process_point($p3); // コンパイルエラーにならない！
}
一見するとこれはポリモーフィズムの恩恵に見える。しかし、ドメインロジックが「正確に2つのキーしか持たないこと」を前提としている場合、この暗黙のアップキャスト（あるいはダウンキャスト的な構造受容）は、致命的なバグの温床となる。
—
2. オプショナルキー（`?`）が生む「不在」と「未定義」の曖昧さ
Shapeのもう一つの危険な機能が、オプショナルキー（`?T`）である。
int,
?’retries’ => int,
);
function configure(UserConfig $config): void {
// キーが存在しない場合と、明示的にnullが渡された場合の曖昧さ
$timeout = Shapes::idx($config, ‘timeout’, 30);
// …
}
HHVMのランタイムにおいて、オプショナルキーが省略されたShapeと、キーが存在して値が `null` であるShapeは、アレイのハッシュバケットの有無という微妙な違いを生む。厳格な静的解析を行っているつもりでも、Shapeの柔軟性は「データの完全性（Data Integrity）」を緩慢に破壊する。
さらに最悪なのは、外部APIやデータベースからのシリアライズ/デシリアライズ境界において、Shapeが無名の構造体であるために、不正なペイロードが境界をすり抜けてドメイン層の奥深くへと侵入する点だ。
—
3. 名前付き型（Class / Record / XHP）への移行戦略
では、どのような基準で Shape と名前付き型を使い分けるべきか？
チーフアーキテクトとしての結論は明快だ。「ドメインモデルのアイデンティティを持つものは、すべて名前付き型（Classまたは値オブジェクト）に落とし込め」。
比較マトリクス
| 評価軸 | Shape (`shape(…)`) | 名前付きクラス (`class`) |
| :— | :— | :— |
| 構造的部分型 | あり（キーの包含関係で推論） | なし（名義的型付け / Nominal Typing） |
| メソッドの付与 | 不可能（データのコンテナに徹する） | 可能（振る舞いとデータのカプセル化） |
| ランタイムメモリ | 配列（HT）としてアロケート | オブジェクト（ObjectData）としてアロケート |
| 推奨ユースケース | 関数間の一時的な軽量多値返却、内部設定の束 | 永続化ドメインモデル、境界を越えるDTO、振る舞いを持つオブジェクト |
正しいリファクタリング例：Shapeから厳格なクラスへ
先ほどの `Point` の例を、名義的型付け（Nominal Typing）を持つクラス構造へリファクタリングする。これにより、意図しない構造的互換性を完全に排除する。
>
final class Point2D {
public function __construct(
public float $x,
public float $y,
) {}
}
final class Point3D {
public function __construct(
public float $x,
public float $y,
public float $z,
) {}
// 2次元への射影を明示的なメソッドとして定義する
public function to2D(): Point2D {
return new Point2D($this->x, $this->y);
}
}
function process_point(Point2D $p): void {
echo “X: {$p->x}, Y: {$p->y}\n”;
}
<<__EntryPoint>>
function main_secure(): void {
$p3 = new Point3D(10.0, 20.0, 30.0);
// 厳格な名義的型付けにより、以下のコードは静的にコンパイルエラーとなる
// process_point($p3);
// 開発者が意図した変換（明示的な射影）を経由させる必要がある
process_point($p3->to2D());
}
このアプローチの利点は、型チェッカーが単なる「キーの有無」ではなく、「型の名前と意図された変換パス」を強制する点にある。
—
4. HHVMのメモリ最適化と型システムのトレードオフ
最後に、低レイヤのメモリ管理の視点からパフォーマンスの選択に言及しておこう。
Shapeは名前付きクラスのインスタンス（`ObjectData`）と比較して、プロパティテーブルのオーバヘッドが少ないため、数百万回アロケートされるような短期的な内部データ構造においてはメモリ効率が良い場合がある。しかし、HHVMのJITコンパイラ（LLVMベースのTC：Translation Cache）は、名義的型付け（Class）されたオブジェクトのプロパティアクセスに対して、よりアグレッシブな型推論とインラインキャッシュ（IC）の最適化を適用する。
構造的部分型に依存したコードは、JIT側から見るとポリモーフィックな呼び出しサイトが増加しやすく、TCのヒット率低下を招く原因になり得る。
アーキテクチャ上の指針
1. システム境界（APIリクエスト、DB読み込み）:
無名のShapeを直接信用してはならない。必ず `Shapes::idx` 等での脆弱なアクセスを避け、アンマーシャリング層で厳格なバリデーションを行い、名前付きクラス（DTO）へと昇格させよ。
2. モジュール内部の局所的スコープ:
関数内部のプライベートなヘルパーや、一時的なデータの束ね方としてのみShapeを限定的に使用せよ。パブリックなAPIシグネチャにShapeを露出させることは、設計上の負債となる。
3. 静的解析の最大化:
`hhconfig` において厳格モードを強制し、`unsafe` なキャストや動的な配列アクセスを排除し続けること。
Hack言語の真の強さは、PHPの動的な柔軟性と、C++やRustに匹敵する静的硬度のハイブリッドにある。Shapeの構造的部分型という「甘美な罠」を断ち切り、型システムの力を極限まで引き出すことこそが、真にスケーラブルなHHVMアーキテクチャを築く唯一の道である。