配列という名の「型なき闇」を断て：HackにおけるTuple活用による堅牢な設計術
コードレビューで未だに `array
HHVMの型チェッカー（Hack Compiler）は、単なる静的解析ツールではない。あれは、コードの意図を数学的に証明するためのゲートキーパーだ。今回は、PHP時代からの悪癖である「配列による複数戻り値」を、Hackの `Tuple` 型でいかにエレガントに、かつ鉄壁の堅牢性を持って再設計するかを説く。
—
なぜ「配列」は設計の敗北なのか
PHPの `array` は、連想配列、リスト、マップ、スタック……と何にでも化ける万能選手だ。だが、この「万能さ」こそが、大規模開発における静的解析の天敵となる。
// 悪い例：返り値の構造がドキュメント頼み
function fetchUserMetadata(int $id): array {
// 戻り値が [bool success, ?string name, int code] なのか、
// それとも [‘status’ => …, ‘data’ => …] なのか、
// 呼び出し側は推測するしかない
return [‘success’ => true, ‘name’ => ‘Alice’, ‘code’ => 200];
}
このコードの何が問題か？
1. 型チェッカーが構造を理解できない: `key` の打ち間違いをコンパイル時に検知できない。
2. 分解時の脆弱性: `list($success, $name) = fetchUserMetadata($id);` と書いた際、インデックスのズレや欠落がランタイムエラーを招く。
3. メモリ効率: HHVMは、固定構造が明確なデータに対して極めて高い最適化をかける。`array` はハッシュテーブルとして確保されるため、Tupleに比べればメモリフットプリントは冗長だ。
—
Tuple：型安全とパフォーマンスを両立させる「静的構造体」
Hackの `Tuple` は、厳密なサイズと、それぞれの要素に対する独立した型定義を持つ。これを関数定義で活用することで、呼び出し側は確実に「何が返ってくるか」を知る権利を得る。
実践：Tupleによる戻り値の分解
以下のコードを見てほしい。これが、今のHackが要求する「生産性と安全性の交差点」だ。
namespace App\Infrastructure;
/
- Tupleを活用した安全なデータ取得関数
- 戻り値は (bool, string, int) の固定構造であることを保証する
/
function fetchUserStatus(int $userId): (bool, string, int) {
// 複雑なビジネスロジックの結果をTupleにパッキング
// HHVMはこの構造をスタック上で最適化し、動的なハッシュ検索を排除する
return (true, “Active”, 200);
}
function processUser(int $id): void {
// 分解代入（Destructuring）で一気に変数へ展開
// 型推論により $isActive, $status, $code には正しい型が割り当てられる
let ($isActive, $status, $code) = fetchUserStatus($id);
if ($isActive) {
// ここでは $status が string であることが型チェッカーによって保証されている
\echo “User status: {$status} (Code: {$code})”;
}
}
この設計のメリット
- 型安全性の担保: `fetchUserStatus` の戻り値構造を変更した場合、呼び出し側の分解箇所で即座にコンパイルエラーが発生する。修正漏れが物理的に不可能になる。
- IDE/LSPの恩恵: 戻り値の型が確定しているため、オートコンプリートが完璧に機能する。
- HHVMの最適化: `Tuple` は内部的に `TypedArray` として展開されるため、ハッシュマップを探査するオーバーヘッドがない。ループ内で数百万回コールされるようなホットパスにおいて、この差は無視できない。
—
次のレベル：名前付きTuple（Shape）との使い分け
「Tupleだけでは、要素の意味（インデックスの意味）を忘れてしまう」という懸念があるなら、それは `Shape` の出番だ。
- Tupleを使うべき場面: 戻り値の意味が文脈から明らか（例: `(int, int)` での座標など）で、一時的な分解が主目的の場合。
- Shapeを使うべき場面: 戻り値の各要素に名前を付けることで、コードの可読性を劇的に向上させたい場合。
// Shapeを用いたより明示的な定義
type UserResult = shape(
‘is_active’ => bool,
‘username’ => string,
‘http_code’ => int,
);
function fetchUserNamed(int $id): UserResult {
return shape(‘is_active’ => true, ‘username’ => ‘Bob’, ‘http_code’ => 200);
}
—
結論：コードは「書くもの」ではなく「定義するもの」
プロフェッショナルなHackエンジニアにとって、配列を返す関数を書くことは、型システムに対するサボタージュと同義だ。
1. 戻り値は明確に定義せよ: `array` は避け、`Tuple` か `Shape` を使え。
2. 分解代入を駆使せよ: 変数への代入をスマートに行い、不要な一時変数を減らせ。
3. 静的解析を信じろ: コンパイルが通るコードは、少なくとも「型」という観点では正当であるという確信を持て。
Hackという言語の重みは、その厳格な型システムにある。この重みを「足枷」ではなく「武器」として使いこなすことが、システム全体の信頼性を底上げする唯一の道だ。今日から既存の `array` を、すべて `Tuple` へ置き換えるリファクタリングを始めろ。それが、君の書くコードが次のステージへ進む第一歩となる。