HaxeマクロでPHPのDIコンテナを自動生成せよ：型安全のその先へ
HaxeのPHPターゲットを利用している諸君。`php.Lib` を使って原始的なコードを書き散らしたり、SymfonyやLaravelの広大な設定ファイルと睨めっこして疲弊してはいないか？
PHPは素晴らしい言語だが、大規模開発においてDIコンテナの設定管理は「静的型付けの欠如」という最大の弱点を抱えている。しかし、我々にはHaxeがある。Haxeのマクロシステムを使えば、コンパイル時に依存関係を静的に解析し、DIコンテナの設定ファイルを「型安全に」自動生成できる。
本稿では、手作業の設定から脱却し、Haxeのコンパイルプロセスそのものをエンジニアリングの味方にするための極限の設計パターンを授ける。
—
1. なぜ「手書き」のDI設定が地獄を生むのか
DI設定ファイル（YAMLやPHP配列）は、コードとの乖離が避けられない。クラス名を変えた瞬間に設定が死ぬ。これを解決するために、我々は「実行時リフレクション」に頼りがちだが、それはPHPのパフォーマンスを殺す。
Haxeのマクロなら、コンパイル時にクラスのメタデータを抽出できる。 これにより、実行時にはゼロオーバーヘッドで、完璧に整合性の取れた設定ファイルを生成できるのだ。
—
2. 実装パターン：`@:build` による自動スキャン
まずは、特定のインターフェースやメタデータを持つクラスを検出し、その依存関係を抽出するマクロを構築する。
ターゲットとなるクラスの定義
まず、DIの対象であることを示すメタデータ `@:di` を定義する。
// 依存関係注入の対象であることを示すメタデータ
@:autoBuild(macros.DiMacro.build())
interface Injectable {}
DI構築用マクロの実装
`macros.DiMacro` は、コンパイル時にAST（抽象構文木）を走査し、クラス名とコンストラクタの引数を抽出してJSON/YAMLに書き出す。
package macros;
if macro
import haxe.macro.Expr;
import haxe.macro.Context;
import haxe.macro.Type;
class DiMacro {
public static function build():Array
var cls = Context.getLocalClass().get();
var className = cls.pack.concat([cls.name]).join(‘.’);
// コンストラクタの引数を取得して依存関係を特定
var constructor = cls.constructor.get();
var deps = constructor.type.getParameters().map(arg -> {
return arg.name; // ここで型情報を取得して依存リストを構築
});
// ここでコンパイルキャッシュまたは外部ファイルに書き出す
// 実際の現場では static var でメモリに溜めておき、最後に書き出す
trace(‘Registering component: $className with deps: $deps’);
return Context.getBuildFields();
}
}
end
—
3. パフォーマンスを最大化するための「静的結合」の知見
マクロで生成した情報を、どのようにPHPのDIコンテナ（Symfonyなど）に渡すべきか？
- コンパイル時書き出し: マクロの最後で `haxe.macro.Context.onAfterGenerate` をフックし、全クラスの走査が完了したタイミングで最終的な `services.yaml` を生成する。これにより、IOオーバーヘッドを最小化できる。
- 抽象型の活用: PHP側のDIコンテナが期待する型と、Haxeの型定義が微妙に異なる場合、`abstract` を活用して自動的にPHPのクラス名文字列に変換させる。
現場で即戦力となるプロダクションコード例
// コンパイル終了時に設定を一括出力するフック
if macro
Context.onAfterGenerate(function() {
var config = DiRegistry.finalize(); // 蓄積した情報を取得
sys.io.File.saveContent(‘config/services.yaml’, generateYaml(config));
});
end
—
4. 陥りやすい罠：循環参照と過剰な抽象化
このアプローチを取る際、多くのエンジニアが「循環参照」で躓く。
1. 依存グラフの可視化: マクロ内で `haxe.macro.Type` を辿り、循環参照があればコンパイルエラー（`Context.error`）を投げること。実行時に `Fatal Error` を出すのは三流の設計だ。
2. プロキシの利用: どうしても循環が必要な場合は、コンストラクタではなくセッター注入にするか、DIコンテナの「遅延ロード（Lazy loading）」機能を活用するよう、マクロ側で型を判定して制御せよ。
—
結論：Haxeは「トランスパイラ」ではなく「コンパイラ」である
多くのエンジニアは、Haxeを単なる「PHPへの変換器」と勘違いしている。だが、真の使い手にとってHaxeは「メタプログラミング可能な静的解析エンジン」だ。
DIコンテナの設定ファイルをマクロで生成するということは、「コードが自分自身を構築する」ということ。一度この設計を導入すれば、手作業の設定ミスによる障害はゼロになり、開発のスピードは劇的に向上する。
さあ、今すぐプロジェクトの設定ファイルを削除し、マクロによる自動生成に置き換えるのだ。コードの整合性を担保するのは人間ではなく、コンパイラの仕事であるべきなのだから。
—
追伸：もし特定のDIフレームワーク（SymfonyのDICなど）への特化実装が必要なら、各社のコンテナ定義の仕様書を読み込み、マクロの `generateYaml` 部分を各フレームワークのスキーマに合わせて調整せよ。本質は「型情報の抽出」にある。