序：Partialという名の「妥協」、そしてStrictという名の「規律」
HHVM上で稼働するHack言語において、静的型システムは単なるコードの飾りではない。それは、JITコンパイラ（TC：Translation Cache）がネイティブマシン語への最適化を極限まで推し進めるための、言わば「動かない真実」である。
だが、現実のプロジェクトは残酷だ。何百万行ものレガシーなPHPコードベースを、ある日突然すべて `<<__STRICT__>>` に書き換えるなどというおとぎ話は、現場のエンジニアには通用しない。だからこそ我々は `<<__Partial__>>` モードという安全弁を持つ。しかし、このPartialとStrictの混在環境こそが、技術的負債の隠れ蓑となり、型安全性の崩壊を招く最大の魔窟であることを知るべきだ。
本稿では、レガシーなPartial環境の海に溺れることなく、段階的かつ鉄壁の戦略をもってコードベースをStrictへと昇華させるための極限の知見を授ける。
—
1. 型チェッカーの盲点：Partial環境がもたらす「静かなる腐敗」
Partialモードの最大の問題は、`mixed` 型の蔓延と、型推論の「甘え」にある。Partialファイル内では、型注釈が省略された式は暗黙的に `mixed`（あるいはそれに準ずる緩い推論）として扱われる。
ここで恐ろしいのは、StrictモードのファイルからPartialモードの関数を呼び出した瞬間に何が起きるかだ。
// [Strict Mode]
<<__STRICT__>>
namespace Hack\Expert;
function process_user(User $user): void {
// Partialで定義されたレガシー関数を呼び出す
$data = LegacyModule::fetchUserData($user->getId());
// 型チェッカーは $data を「信用せざるを得ない」
// だが、この $data の中身が実際には何であるかは、Runtimeまで保証されない
echo $data[‘name’];
}
HHVMの型チェッカー（`hh_client`）は、静的な境界線（StrictとPartialの境界）を越える際、Partial側の型定義の曖昧さをそのまま許容せざるを得ない場合がある。これにより、静的解析の網をすり抜けた型違反が、プロダクション環境で致命的な `TypeHintException` や予期せぬ配列アクセスの崩壊を引き起こすのだ。
—
2. 移行期を生き抜くための設計パターン：境界の封じ込め（Boundary Containment）
段階的移行（Incremental Migration）において最もやってはいけないのは、Partialな関数やクラスをそのままStrictなコードのあちこちに散りばめることだ。
移行期における鉄則は、「アンチパターンを特定の防壁（アダプター）の向こう側に隔離する」ことである。
以下のコードは、レガシーなPartialモジュールとモダンなStrictモジュールの間に立ち、型安全性を強制的に担保するAPI Gateway / Adapterパターンの実装例だ。
<<__STRICT__>>
namespace Hack\Expert\Migration;
/
- 外部のレガシーなPartial実装（修正不可能なモジュール）を想定
/
// <<__Partial__>>
// class LegacyApiClient { … }
/
- 【設計パターン】Strict境界アダプター
- Partialコードとの接触面をこのクラス内だけに限定し、
- 外部へは完璧なStrict型を担保して露出させる。
/
final class StrictUserAdapter {
private function __construct(
private int $id,
private string $email,
) {}
/
- レガシーな配列データを厳格なオブジェクトへ昇華させる境界メソッド
- ここで実行時バリデーションを行い、型安全性の担保を完了させる。
/
public static function fromLegacyRawData(mixed $rawInput): this {
// HHVMのパターンマッチングまたは厳格な型ガード
invariant(
is_dict($rawInput),
‘Legacy data must be a dict, %s given.’,
gettype($rawInput)
);
$id = $rawInput[‘id’] ?? null;
$email = $rawInput[‘email’] ?? null;
invariant(
is_int($id) && is_string($email),
‘Type violation at the Strict Boundary: invalid payload structure.’
);
return new self($id, $email);
}
public function getId(): int {
return $this->id;
}
public function getEmail(): string {
return $this->email;
}
}
チーフアーキテクトのコードレビュー
> 「なぜこのアダプターが必要なのか？」
> `mixed` を受け取る境界において、`invariant()` を用いた厳格なランタイムアサーションを行っている点に注目せよ。静的型チェッカーはコンパイル時の保証しかできない。Partialと混在する環境では、「静的型の信頼が途切れる境界線でのランタイム型ガード」こそが、システム全体をクラッシュから守る唯一の盾となる。
—
3. 非同期API連携とGenericsにおける厳格性の維持
非同期処理（`Awaitable`）やGenericsを多用するモダンなHackコードベースにおいて、Partialモードのコードが混入すると、型推論の連鎖が容易に破壊される。
特に Async API のレスポンス処理において、型安全性を維持しながら段階的移行を進めるための実践的な実装を見ていこう。
<<__STRICT__>>
namespace Hack\Expert\AsyncPipeline;
use namespace HH\Asio;
interface IResponseTransformer
public function transform(mixed $raw): T;
}
final class UserResponseTransformer implements IResponseTransformer
public function transform(mixed $raw): UserEntity {
// 境界での型検証
invariant(is_shape($raw, UserEntity::class), ‘Invalid user shape’);
return UserEntity::fromShape($raw);
}
}
final class StrictAsyncPipeline {
/
- 段階的移行期間中でも、非同期パイプラインの末端で型安全性を強制する。
/
public async function fetchAndTransformAsync
string $endpoint,
IResponseTransformer
): Awaitable
// レガシーなHTTPクライアント（Partial想定）からの生レスポンス取得をシミュレート
$rawResponse = HH\Asio\join($this->callLegacyClientAsync($endpoint));
// 変換レイヤーを必ず経由させることで、型汚染を上流へ伝播させない
return $transformer->transform($rawResponse);
}
private async function callLegacyClientAsync(string $endpoint): Awaitable
await Asio\usleep(10000);
return dict[‘id’ => 42, ‘email’ => ‘architect@hack-lang.org’];
}
}
—
4. パフォーマンス上の注意点：型チェックのオーバーヘッドとHHVMの最適化
「Strictモードにするとパフォーマンスが上がる」という神話は半分正しく、半分は誤りだ。
1. JITコンパイルの恩恵: Strictモードでは、変数の型が完全に確定しているため、HHVMのTC（Translation Cache）は無駄な型ガード命令（Type Guard Instructions）やボックス化（Boxing）を排除し、ネイティブなレジスタ操作に近い高速なコードを生成できる。
2. 境界でのコスト: 逆に、StrictとPartialが頻繁に交差する箇所では、境界を越えるたびにランタイムでの型チェックやアンボックス処理が発生し、これがマイクロベンチマークレベルでのボトルネックになり得る。
だからこそ、「ファイルをモジュール単位でまとまってStrict化する（Bottom-up / Inside-out 移行戦略）」が必須なのだ。依存関係の末端（Leaf nodes）にあるモデル層やユーティリティ層から完全にStrict化し、依存の根幹（Root nodes）に向かって徐々に領域を広げていくこと。これがHHVMのパフォーマンスを最大限に引き出す王道である。
—
結：技術的負債に勝つためのアーキテクチャの意思
大規模コードベースのStrict化は、開発チームの規律そのものである。「動けばいい」という妥協の産物であるPartialモードを、段階的に、しかし確実に駆逐していくこと。
型チェッカーを単なるエラー検出ツールとして使うな。型チェッカーを「未来のバグをコンパイルすらさせないための絶対的な法律」として君臨させろ。その環境を構築できたとき、あなたの書くHackコードは、圧倒的なパフォーマンスと美しさを手に入れることになる。