—
トレイトの枷：`require extends` と `require implements` が紡ぐ型システムの規律
PHPにおけるトレイトは、単なる「コードのコピペ（水平的再利用）」に過ぎなかった。しかし、我々がHHVMとHackを設計した際、その無秩序な再利用性にメスを入れ、厳格な静的型付けの支配下に置くことを決意した。
Hackの型チェッカー `hh_server` にとって、トレイトは「不完全な断片」である。その断片がどのコンテキストで展開されるかを事前に定義せずして、真の型安全は成立しない。ここで重要になるのが、`require extends` と `require implements` という強力な制約（Constraints）だ。
本稿では、トレイトを「単なる便利な混合物」から「アーキテクチャ上の厳格な契約」へと昇華させる、これら制約の深層を解剖する。
—
1. PHPトレイトの「盲目性」とHackの解法
PHPのトレイトは、自身が注入されるホストクラスの構造を全く把握していない。そのため、トレイト内で `$this->someMethod()` を呼び出す際、そのメソッドが存在するかどうかは実行時の運任せとなる。
Hackの Strict Mode は、この不確実性を許さない。
abstract trait TLogger {
// 制約なしにメソッドを呼ぶことは許されない
public function logInfo(string $msg): void {
// Error: Method ‘formatMessage’ is undefined
$formatted = $this->formatMessage($msg);
echo $formatted;
}
}
この問題を解決するのが `require extends` だ。これにより、トレイトは「私はこのクラスのサブクラスにしか組み込まれない」という契約を型チェッカーと結ぶ。
—
2. `require extends`: 継承関係の型保証
`require extends` は、トレイトが特定のクラスの継承ツリーに属することを強制する。これにより、トレイト内で親クラスの `protected` メソッドやプロパティに安全にアクセスできるようになる。
実装例：データベース・アクセス・エンティティ
namespace TechArch\Core;
abstract class BaseRepository {
protected function getConnection(): \PDO {
// 接続プールの管理ロジック
return new \PDO(‘dsn’);
}
}
trait TAuditable {
// このトレイトは BaseRepository を継承したクラスにしか使えない
require extends BaseRepository;
public function logAccess(int $userId): void {
// require extends により、getConnection() が存在することが
// 静的に保証される。実行時のオーバーヘッドはない。
$db = $this->getConnection();
$stmt = $db->prepare(“INSERT INTO access_logs (user_id) VALUES (?)”);
$stmt->execute([$userId]);
}
}
final class UserRepository extends BaseRepository {
use TAuditable; // OK
}
// class ExternalService { use TAuditable; }
// ↑ これは型チェック時に拒否される。ExternalService は BaseRepository を継承していない。
低レイヤの視点：HHVMのJIT最適化
HHVMのJITコンパイラにとって、`require extends` は強力なヒントになる。
トレイト内の `$this` が特定の型（またはその派生）であることが保証されるため、メソッドディスパッチにおいて vtable（仮想関数テーブル）のオフセットを推論しやすくなる。
型制約がない場合、HHVMは実行時に `InstanceMethodCache` を参照せざるを得ないが、制約によって型が絞り込まれていれば、よりダイレクトなマシンコードを生成し、投機的な最適化（Speculative Optimization）の的中率を向上させることが可能だ。
—
3. `require implements`: インターフェースによる能力定義
`require extends` が実装の共有を強制するのに対し、`require implements` は「振る舞い（能力）」を強制する。これは、複数の異なるクラス階層にまたがって、特定のインターフェースを備えていることを前提としたロジックを注入する場合に極めて有効だ。
実装例：シリアライズ可能なセキュリティ・トークン
interface ISerializable {
public function serialize(): string;
}
trait TSecurityToken {
require implements ISerializable;
public function getEncryptedToken(): string {
// serialize() の存在が保証されている
$data = $this->serialize();
return \hash_hmac(‘sha256’, $data, ‘secret-key’);
}
}
class UserSession implements ISerializable {
use TSecurityToken; // OK
public function serialize(): string {
return “session_data”;
}
}
この制約の真価は、多重継承の安全なシミュレーションにある。Hackはクラスの多重継承を禁止しているが、トレイトと `require` 制約を組み合わせることで、特定の「能力」を持つクラスに対してのみ機能を追加する「ミックスイン」を、型安全に実現できる。
—
4. アーキテクチャの境界防衛
セキュリティ研究者やシニアアーキテクトの視点から見れば、これらの制約は単なる「エラー防止」以上の意味を持つ。それは 「不適切なコンテキストでのコード利用の阻止」 である。
例えば、機密情報を扱う `TCrypto` トレイトがあるとする。このトレイトが `require extends InternalSecureBase` を持っていれば、外部公開される可能性のある `PublicController` で誤って `use TCrypto` されることを、CI（継続的インテグレーション）の段階で確実に阻止できる。
型チェッカー `hh_server` の挙動
`hh_server` は、ファイルが保存されるたびに、依存関係グラフ（Dependency Graph）をスキャンする。
1. `use` されているトレイトを特定。
2. トレイト内の `require` 制約をロード。
3. ホストクラスの継承ツリーおよび実装インターフェースと照合。
4. 矛盾があれば、バイトコード生成前に Fatal Error を投げる。
これは、ランタイムで `method_exists` や `instanceof` を連発する「防御的プログラミング」を排除し、「ゼロ・オーバーヘッドの安全性」 を実現するための根幹技術である。
—
5. 結論：規律がもたらす自由
Hackにおけるトレイトの制約は、開発者に不自由を強いるためのものではない。むしろ、コンパイラに対して明確な意図を伝えることで、より高度な抽象化と、高速な実行性能を両立させるための「契約」である。
- `require extends` は、実装の基盤を固定し、内部構造への安全なアクセスを保証する。
- `require implements` は、振る舞いの要件を定義し、ポリモーフィズムをトレイトレベルで実現する。
我々がHHVM/Hackで目指したのは、動的言語の柔軟性と静的型付けの堅牢性の融合だ。このトレイトの制約を使いこなすことは、システムの「重み」を理解し、真にスケーラブルなアーキテクチャを設計する第一歩となる。
コードを書くのではない。型システムという名のキャンバスに、論理の構造を描くのだ。