こんにちは！Haxeの世界へようこそ。
今回は、Haxeの真骨頂である「マクロシステム」と、Web開発の現場で欠かせない「PHPターゲット」を組み合わせた、最高にエキサイティングなテーマをお届けします。
他の言語からHaxeにやってきた開発者なら、きっとこう思ったことがあるはずです。
「Haxeの強力な型システムで書いたコードをPHPにトランスパイルできるなら、PHP側の面倒な設定ファイルもHaxeから自動生成できないか？」と。
結論から言いましょう。完全に可能です。
今回は、Haxeのマクロを使ってクラス構造をコンパイル時にスキャンし、LaravelやSymfonyといったPHP製フレームワークで使える「型安全なDI（依存性注入）コンテナの設定ファイル」を自動生成するパイプラインを構築してみましょう。
ここをクリアすれば、あなたもHaxeのメタプログラミングを自在に操るアーキテクトの仲間入りです。一緒に一歩ずつ進んでいきましょう！
—
なぜ「Haxe × PHP × DIコンテナ」なのか？
現代のPHPアプリケーション開発において、DIコンテナ（依存性注入）は避けて通れないアーキテクチャです。しかし、PHP側でコンテナの設定ファイル（YAMLやXML、あるいはPHPの配列）を手書きしていると、次のような問題に直面します。
- クラス名を変えたときに設定ファイルの書き換えを忘れて、実行時エラー（`Class not found`）になる。
- タイポしてもPHPを実行するまで気づけない。
Haxeはコンパイル時にすべての型を知っています。ならば、「コンパイル時にクラスの依存関係を解析し、PHPが読み込める設定ファイルを自動で吐き出せばいい」のです。手書きのミスレガシーとは今日でお別れしましょう。
—
全体像：コンパイル時自動生成パイプライン
今回の仕組みを視覚的に捉えてみましょう。
[Haxeのソースコード（@injectメタデータ付与）]
↓
(Haxeコンパイラ)
↓
[マクロがコードを静的解析] ──→ コンパイル時に自動実行！
↓
[PHP用DI設定ファイル (di_config.php / json)]
↓
[PHPランタイムが読み込んで安全に依存解決]
Haxeのコンパイルが走るたびに、最新のクラス構造を反映したPHP用の設定ファイルが自動で更新されます。
—
実装ステップ
それでは、実際にコードを書いていきましょう。今回はシンプルに、アノテーション（メタデータ）が付与されたサービスクラスをスキャンし、PHPの配列形式のDI設定を出力するマクロを作ります。
1. 依存性注入の対象となるHaxeクラスの定義
まずは、DIコンテナに登録したいHaxeのクラスを用意します。ここでは `@inject` というメタデータを付与することにします。
// UserService.hx
package services;
@:build(macros.DiMacro.buildService())
class UserService {
public function new() {}
public function getUserData(id:Int):String {
return “User #” + id;
}
}
ここで使っている `@:build(macros.DiMacro.buildService())` がHaxeのマクロ機能です。「このクラスがコンパイルされる時に、`DiMacro`というマクロプログラムを走らせてね」という指示になります。
2. マクロの実装：コンパイル時にクラスをハントする
次に、クラス構造を読み取ってPHP用の設定ファイルを出力するマクロ本体を書きます。
Haxeのマクロは、「Haxeのコードを書いて、Haxeのコンパイルをハックする」という強力なアプローチです。
// macros/DiMacro.hx
package macros;
if macro
import haxe.macro.Context;
import haxe.macro.Expr;
import sys.Io;
end
class DiMacro {
// 登録されたサービスを蓄積する静的リスト
private static var registeredServices:Array
macro public static function buildService():Array
// 現在コンパイルしているクラスの情報を取得
var cls = Context.getLocalClass().get();
var className = cls.pack.concat([cls.name]).join(“.”);
// 蓄積リストに追加（重複を防ぐ）
if (registeredServices.indexOf(className) == -1) {
registeredServices.push(className);
}
// 毎回のビルド終了時に、一度だけ設定ファイルを出力するフックを登録
Context.onGenerate(function(types) {
generatePhpDiConfig(registeredServices);
});
// クラス自体のフィールド（メソッドや変数）は変更しないのでそのまま返す
return Context.getBuildFields();
}
private static function generatePhpDiConfig(services:Array
var phpCode = “ \\DI\\autowire(\\$phpClassName::class),\n’;
}
phpCode += “];\n”;
// PHP側の出力先ディレクトリにファイルを書き出す
sys.io.File.saveContent(“www/di_config.php”, phpCode);
Sys.println(“[Haxe Macro] PHP DI config successfully generated!”);
}
}
3. このコードのポイントと意味
ここまでのコードで重要なポイントを整理しておきましょう。
1. `Context.getLocalClass()`:
今まさにコンパイルされようとしているクラスのメタデータにアクセスします。クラス名やパッケージ名を完全修飾名で取得できるため、「どのクラスが存在するか」を完全に取り逃がしません。
2. `Context.onGenerate()`:
Haxeコンパイラがすべての型チェックとトランスパイルの準備を終え、コードを生成する直前のタイミングで実行されるコールバックです。これを使うことで、全クラスのスキャンが完了したあとに、まとめて1つの設定ファイルを出力できます。
3. 完全な型安全性:
もしHaxe側でクラス名をリファクタリング（変更）すると、マクロもそれに追従するため、生成されるPHP設定のクラス名も自動的に新しいものに書き換わります。PHP側で「スペルミスした！」という絶望とはもうお別れです。
—
陥りやすい文法エラーと注意点
Haxeのマクロを書き始めるとき、多くの開発者が以下の罠にハマりがちです。ここをクリアすればバッチリマスターできますよ！
1. サーバーサイド（ターゲット）コードとマクロコードの混同
- エラー例: マクロの関数内（`#if macro` の中）で、PHPターゲット専用のランタイム関数や外部ライブラリを呼び出そうとしてコンパイルエラーになる。
- 原因: マクロは「Haxeコンパイラを動かしているホスト環境（通常はNeko VMやJVM、Node.jsなど）」の上で実行されます。PHPのコードを出力することはできますが、マクロの実行中にPHP固有のランタイムは動いていません。
- 解決策: マクロ内で動かすコードは、必ず `#if macro` で囲み、純粋なHaxeの標準ライブラリ（`sys.` など）を使って記述するようにしましょう。
2. パスのスラッシュとバックスラッシュの混乱
- 注意点: Haxeのパッケージ区切りはドット（`.`）ですが、PHPのネームスペースはバックスラッシュ（`\`）です。文字列として出力する際は、必ず `StringTools.replace` などで適切に置換してあげる必要があります。
—
まとめ
今回は、Haxeのマクロシステムを活用して、コンパイル時にPHPのDIコンテナ用設定ファイルを自動生成するパイプラインを構築しました。
- Haxeはコンパイル時にコードの構造を完全に把握できるため、メタデータ（`@:build`）と組み合わせることで無限の可能性が広がります。
- マクロの `Context.onGenerate` を使えば、ビルドの最後に設定ファイルなどを一括出力するスマートな仕組みが作れます。
- クロスプラットフォーム言語であるHaxeだからこそ、PHPのような動的言語のエコシステムを「静的型の安全網」でガッチリと保護することができるのです。
Haxeのメタプログラミングは、最初は少し難しく感じるかもしれませんが、一度この強力な自動化の快感を覚えると、もう手書きの設定ファイルには戻れなくなりますよ。
あなたのHaxeライフが、さらに快適でプロダクティブなものになりますように。それではまた、次の高度な知見でお会いしましょう！