Hackを掌握する極限の知見：Strict ModeにおけるShapeの構造的型付けとインターフェースの境界線
HHVMのコアエンジニアリング、そしてHack言語の静的型チェッカーの進化を最前線で見つめてきた者として、我々が日々直面するアーキテクチャ上の究極の問いに切り込もう。それは、「データの構造（Shape）と、振る舞いの抽象（Interface）の境界線をどこに引き、ランタイムのパフォーマンスと型の安全性を極限まで両立させるか」という問題だ。
世の中の入門書は「Shapeは連想配列の型安全なラッパーである」といった表層的な解説で満足する。だが、シニアエンジニアやセキュリティ・ランタイムの深淵を覗く者にとって、コンパイル時の型消去（Type Erasure）、HHVMのJITコンパイラにおけるメモリレイアウト、そして構造的型付け（Structural Subtyping）がもたらすバイナリレベルの最適化の恩恵を知らぬ者は、Hackの真のポテンシャルを引き出せていないと言わざるを得ない。
今回は、Strict Mode下におけるShapeの厳密な挙動と、オブジェクト指向インターフェースの使い分けについて、コンパイラ内部のメカニズムを交えながら極限まで深掘りする。
—
1. 構造的型付けの罠：Shapeは本当に「ただのデータ構造」なのか？
Hackの `shape` は、キーと値の型が固定されたヘテロジニアスなデータ構造だ。しかし、オブジェクトの公称的型付け（Nominal Typing）とは異なり、Shapeは構造的サブタイピング（Structural Subtyping）の哲学に基づいている。
ここで、HHVMの型チェッカー（`hh_client`）が裏で何を行っているかを知る必要がある。
<<__Strict>>
namespace HackConnoisseur\Core;
type Point2D = shape(‘x’ => float, ‘y’ => float);
type Point3D = shape(‘x’ => float, ‘y’ => float, ‘z’ => float);
function process_point(Point2D $p): void {
// 座標の処理
}
function execute(): void {
$p3d = shape(‘x’ => 10.0, ‘y’ => 20.0, ‘z’ => 30.0);
// 構造的サブタイピングの魔法：
// Point3DはPoint2Dが要求する構造を完全に満たしているため、型チェックを通過する。
process_point($p3d);
}
コンパイラの視点：なぜこれが成立するのか？
Hackの型チェッカーにおいて、フィールドが多いShape（`Point3D`）は、少ないShape（`Point2D`）に対して「より具体的な構造（Width Subtyping）」を持つとみなされる。つまり、`Point3DはPoint2Dのサブタイプ`である。
しかし、これをランタイム（HHVM）の視点で見ると、事態は少し異なる。HHVMのバイトコードレベルにおいて、Shapeは最適化された配列（Ht / HashTable）あるいは特定のメモリスロットとして表現される。構造的サブタイピングの安全性はすべてコンパイル時の静的解析によって保証されており、実行時には不要なプロパティは単に無視されるか、そのまま保持される。
ここで重要なのは、「Shapeはオブジェクトではない」という点だ。仮想メソッドテーブル（vtable）を持たず、インスタンス化のオーバーヘッドも極小であるため、大量のD-DTO（Data Transfer Object）を扱うマイクロサービスやAPI層において、メモリ消費量を極限まで抑える武器となる。
—
2. DTOとしての最適解：Shape vs Interface (readonly properties)
では、APIの境界や外部サービスとのデータ転送（DTO）において、我々はいつShapeを使い、いつInterface（あるいはクラス）を使うべきか。
結論から言えば、「振る舞い（メソッド）を持たず、純粋なデータのやり取りに徹する場合」はShape一択である。逆に、「データに対してポリモーフィックな振る舞いを期待する場合」や「カプセル化と不変性の保証を厳密に行いたい場合」はInterfaceとClassを選択すべきだ。
以下のコードを見てほしい。Strict Modeにおける両者のコントラストだ。
<<__Strict>>
namespace HackConnoisseur\DTO;
// — パターンA: ShapeによるDTO —
type UserShape = shape(
?’id’ => int, // 存在しないかもしれないフィールドはオプショナル
‘name’ => string,
‘email’ => string,
);
// — パターンB: インターフェースによる抽象化 —
interface IUser {
public function getId(): ?int;
public function getName(): string;
public function getEmail(): string;
}
final class ImmutableUser implements IUser {
public function __init__(
private ?int $id,
private string $name,
private string $email,
) {}
public function getId(): ?int { return $this->id; }
public function getName(): string { return $this->name; }
public function getEmail(): string { return $this->email; }
}
メモリとパフォーマンスの境界線
HHVMのJIT（Translation Cache）は、クラスのプロパティアクセスに対してプロパティマップ（Property Map）やInline Cachingを活用して最適化を行う。しかし、インスタンス生成（`new`）のコスト、ガベージコレクション（GC）のプレッシャーは、数百万件のレコードを処理するパイプラインでは無視できない。
一方、Shapeはプリミティブな配列ベースのストレージとして扱われるため、次のようなメリットがある：
1. アロケーションの軽量さ: オブジェクトヘッダのオーバーヘッドが非常に小さい。
2. シリアライゼーションの容易さ: `json_encode` や外部ストレージへのマッピングが直感的かつ高速。
3. 完全なイミュータビリティの強制: Strict Mode下では、Shapeのフィールドの書き換えは厳しく制限され、副作用のないデータフローを構築しやすい。
—
3. シニアエンジニアが陥る罠：Shapeの非許容性と型安全性の限界
ただし、Shapeを万能薬だと思ってはならない。構造的型付けゆえの「闇」が存在する。それは、「未知のキー（Unknown Keys）」に対する挙動だ。
Hackでは、デフォルトのShapeは「定義されたキー以外を持っていてもよい（Width Subtypingの許容）」が、もし厳密に「定義されたキー以外の存在をコンパイル時に弾きたい」場合や、逆に許容したい場合、`allows_unknown_fields` のようなアノテーションや、型システムの厳格な管理が必要になる。
特に、外部から入力されるJSONデータを `Shapes::idx` などで処理する際、型チェッカーの目を欺くような動的なキーアクセスを行うと、HHVMのJIT最適化の恩恵（Type Specialization）が失われ、メガモフィックなコードへと堕ちていく。
<<__Strict>>
namespace HackConnoisseur\Security;
type StrictConfig = shape(
‘host’ => string,
‘port’ => int,
);
function configure(StrictConfig $config): void {
// $config[‘port’] は確実に intであることが静的に保証されている。
// HHVMはこの型情報を元に、ボックス化されていないプリミティブな整数演算へJITコンパイルする。
$targetPort = $config[‘port’] + 1;
// …
}
このコード例において、`StrictConfig` が静的に保証されているおかげで、HHVMのランタイムは動的な型チェック（Tag check）を完全にバイパスし、ネイティブなCPU命令レベルでの高速な加算処理を生成できる。これが、Strict Modeと正確な型定義が生み出す最高速のパフォーマンスである。
—
4. アーキテクチャの指針：極限の現場でどう選択すべきか
大規模なHackコードベースを設計するチーフアーキテクトとして、チームに徹底すべき指針を明示しよう。
1. データ層とトランスポート層 (DB, API Payload, JSON Mapping):
- Shapeを使用せよ。 構造的型付けの柔軟性と、軽量なメモリフットプリントを最大限に活かし、DBの行データやHTTPリクエスト/レスポンスの構造をそのまま表現する。
2. ドメインロジックとビジネスルール層:
- InterfaceとClass（readonlyプロパティ）を使用せよ。 ドメインの不変条件（Invariants）をカプセル化し、振る舞いとデータを一体化させることで、堅牢なオブジェクト指向設計を維持する。
3. 境界線の厳守:
- DTOとして入ってきたShapeを、そのままドメインモデルにコンバートするファクトリーメソッド（あるいはMapper）を必ず挟むこと。構造的型付けの緩やかさがドメインの深部にまで浸食するのを防ぐのが、シニアエンジニアの仕事である。
—
結びにかえて
Hack言語とHHVMは、静的型付けの厳格さと、Webスケールの高速性を極限まで高めたモンスター級のプラットフォームである。その中核をなすShapeは、単なる「便利な配列の型付け機能」ではない。構造的型付けという数学的背景を持ち、HHVMのランタイム最適化のポテンシャルを最大限に引き出すための洗練されたツールだ。
言語の仕様の奥底にあるコンパイラの挙動を理解し、型チェッカーを味方につけた者だけが、真にスケーラブルで美しいシステムを構築できる。コードの向こう側にあるランタイムの息吹を感じながら、今日も最高のアーキテクチャを組み上げよう。