境界線をコードで定義せよ：Hack Attributeを用いた静的解析の「聖域」構築
Hackの真髄は、単なるPHPの進化系ではない。それは、型チェッカー（HHVM Typechecker）という「動的な血脈」を、静的な「鉄の規律」で封じ込めるプロセスだ。
多くのエンジニアは、Hackを「型安全なPHP」と誤解している。しかし、真にHackを掌握する者は知っている。Hackは、型チェッカーを拡張し、アプリケーションのドメイン境界をコンパイル時に定義するための「メタ・プログラミング・プラットフォーム」であるということを。
本稿では、汎用的な型定義を超え、`<<__Attribute>>`をフックとして活用し、プロジェクト固有の規約を型チェッカーの解析プロセスに直接埋め込む、極限の静的解析手法を解説する。
—
1. 型チェッカーの「メタデータ」というフック
Hackにおいて、`Attribute`は単なるリフレクション用のメタデータではない。それは、`hh_client`がソースコードを走査する際、AST（抽象構文樹）の特定のノードに突き刺す「アンカー」だ。
我々は、標準の型システムが提供する`int`や`string`の制約を超え、ビジネスロジック固有の「不変条件（Invariant）」を型チェッカーに強制させる必要がある。
実践：機密データ流出を防ぐ「汚染防止」属性
例えば、特定のメソッドが「外部から入力された機密データ」を直接扱わないことを保証したいとする。標準の型システムでは表現困難なこの制約を、カスタム属性で実装する。
namespace App\Security;
// <<__Attribute>> を使用して、型チェッカーへの「指示」を定義
<<__Attribute(__TARGET_METHOD)>>
final class MustBeSanitized implements \HH\ClassAttribute {
public function __construct() {}
}
// 利用側の実装
class UserProfile {
// このメソッドには必ず「サニタイズ済み」のデータを通すという制約を付与
<
public function updateEmail(string $email): void {
// …
}
}
2. カスタム解析器（HHVMアーキテクチャへの介入）
単に属性を付けるだけでは、それは単なるタグに過ぎない。真の力は、`hh_client`が呼び出すカスタムリンター（`Hack Linter`）や、`HH\Typechecker`の内部プロセスを操作することにある。
我々が目指すべきは、`hacklib`や`HHAST`を活用した、プロジェクト専用の「静的解析エージェント」の開発だ。
HHASTを用いたASTの走査と検証
`HHAST`を利用し、`MustBeSanitized`が付与されたメソッドへの引数が、特定のラップクラス（例: `SanitizedString`）で包まれているかを走査するカスタムルールを定義する。
// 概念実証：HHASTを用いた単純な検証ルールの一部
use HHAST;
final class SanitizationRule extends HHAST\Visitors\Visitor {
public function visitMethodDeclaration(HHAST\MethodDeclaration $node): void {
// 1. <
if (!$this->hasAttribute($node, ‘MustBeSanitized’)) {
return;
}
// 2. 引数の型をASTレベルで解析し、SanitizedString型以外であればエラーを投げる
foreach ($node->getParameterList()->getChildren() as $param) {
if (!$this->isSanitizedType($param)) {
// コンパイルタイムにエラーを発生させ、ビルドを停止させる
throw new Exception(“Security Violation: Unsantized input at ” . $node->getName());
}
}
}
}
3. なぜ「型チェッカーのカスタマイズ」が必要なのか
このアプローチを取る理由は明確だ。ランタイムでのチェックは、コストでありリスクだからだ。
1. メモリ最適化: ランタイムのバリデーションは、高頻度で呼び出されるメソッドにおいて、オブジェクトの生成や条件分岐を増やし、アロケータに負荷をかける。静的解析で解決すれば、実行時のメモリフットプリントはゼロになる。
2. 早期の失敗（Fail-Fast）: 本番環境で「型が合わない」と例外を吐くのは敗北である。コンパイルフェーズでCIを落とすことこそが、高可用性を担保する唯一の道だ。
3. カプセル化: アーキテクチャの制約をコードの構造（Attribute）として明示することで、新規参入者やチームメンバーが規約を破る余地を物理的に排除できる。
4. 結び：型は「ドキュメント」ではなく「契約」である
型システムを単なる「型の補助」として捉えるエンジニアは、Hackを3割も使いこなせていない。Hackの真のパワーは、開発者の意図をコンパイラに伝達するその「表現力」にある。
プロジェクト固有のバリデーションを型チェッカーに教え込むことは、チームの知見をコンパイラの挙動に昇華させる行為だ。あなたが定義した`<
これが、我々がHackを選んだ理由であり、到達すべき最高地点だ。
次回のブログでは、HHVMのJITコンパイラがどのようにこれらの「型制約」をプロファイリングし、機械語レベルで分岐予測を最適化しているか、そのバイナリレベルの深淵を覗くことにしよう。
—
Stay hungry, stay compiled.