HaxeでPHP 8.0+ Union Typesを飼いならす：型安全な境界線を引くためのアーキテクチャ
HaxeからPHPターゲットへ出力する際、多くのエンジニアが陥る罠がある。それは「PHP側の動的型付けにHaxeの厳密さをどうマッピングするか」という課題だ。特にPHP 8.0で導入されたUnion Types（例: `int|string`）は、Haxeの静的型システムから見れば「異物」のように映るかもしれない。
しかし、これを「面倒な相互運用」として扱うか、「型安全性を担保する強力な境界線」として設計するかで、プロダクトの堅牢性は天と地ほどの差が出る。今日は、PHPのUnion TypesをHaxeでエレガント、かつ堅牢に扱うための戦略を伝授する。
1. 愚直なマッピングは捨てる：`Abstract`による封じ込め
PHPの `string|int` をHaxeで扱うために `Dynamic` を使うのは、Haxeを使う意義を自ら放棄する行為だ。我々は Abstract型 を用いて、PHP側との通信境界に「検問所」を設置する。
まずは、最も汎用的な「IntまたはString」を要求するPHP APIを想定し、それをHaxe側で定義するパターンを見てほしい。
// PHP側のAPI: function process(int|string $data)
@:transitive
@:forward
abstract MixedData(Dynamic) from Int from String {
// コンストラクタをprivateにすることで、
// 意図しない型が混入するのを防ぐ「静的ガード」を構築する
@:from static function fromInt(v:Int):MixedData return cast v;
@:from static function fromString(v:String):MixedData return cast v;
// PHP側へ渡す直前に、型が正しいか検証するロジックをここに集約できる
public inline function toPhpValue():Dynamic return this;
}
このアプローチの肝は、`@:from` マクロを活用することで、Haxe側では型安全に `MixedData` を生成させつつ、コンパイル結果としてはネイティブなPHPの値として渡せる点にある。
2. インターフェースの境界を定義する：`extern` との賢い付き合い方
Composerパッケージや外部のPHPライブラリを叩く際、`extern` クラスを定義するのは基本だが、Union Typesが絡むと記述が冗長になりがちだ。ここで役立つのが、構造的型付けを活かした「インタフェース定義」である。
もしPHP側が `User|Group` というUnionを要求するなら、Haxe側では共通のインターフェースを持たせるのが定石だ。
// PHP側のクラス構造を想定
extern class PhpProcessor {
public static function handle(entity:Dynamic):Void;
}
// Haxe側での抽象化
abstract EntityUnion(Dynamic) {
public function new(v:Dynamic) this = v;
@:from static function fromUser(u:User):EntityUnion return new EntityUnion(u);
@:from static function fromGroup(g:Group):EntityUnion return new EntityUnion(g);
}
// 利用側
class Service {
public static function run() {
var user = new User();
// コンパイラがEntityUnionへの自動変換を解決する
PhpProcessor.handle(user);
}
}
3. なぜこれで「堅牢」と言えるのか？
このコードが優れている理由は、「型変換の責任を境界線（Abstract）に閉じ込めている」 からだ。
- コンパイル時の最適化: `inline` 関数として定義されているため、ランタイムのオーバーヘッドはゼロに近い。
- 後方互換性: もしPHP側のUnion定義が `int|string|null` に拡張されたとしても、`Abstract` に `fromNull` を追加するだけで、アプリケーション全体を修正することなく対応できる。
- デバッグの容易性: 予期せぬ型が渡された場合、`@:from` の定義場所で確実にコンパイルエラー（あるいは実行時チェックを挿入）できるため、バグの温床を排除できる。
4. 実務で避けるべき「アンチパターン」
最後に、現場でよく見かける「やってはいけないこと」を指摘しておく。
1. `Dynamic` を直接利用する: これはHaxeの強力な推論機能を殺す。`Dynamic` を使うのは、どうしても逃げ道がない時の最終手段であるべきだ。
2. 実行時の型チェックをPHP側に丸投げする: PHPの `is_int()` や `is_string()` をHaxe側で書くのは非効率だ。Haxeのコンパイル段階で型を制約し、PHP側では「正しい型が来ている」という前提で処理する設計を目指すべきだ。
結びに：境界線は「設計の美学」である
Haxeの強みは、トランスパイル先の言語の仕様を「隠蔽」しつつ、その恩恵を最大限に引き出せる点にある。PHP 8.0以降のUnion Typesは、適切に抽象化すれば、堅牢なシステムを構築するための強力な武器になる。
あなたが書くそのコードは、単なるPHPとのブリッジではない。型安全という名の城壁なのだ。次にPHPライブラリと対峙する時は、ぜひこの「境界線設計」を思い出してほしい。
コードは嘘をつかない。設計の甘さは必ずランタイムエラーとして返ってくる。だからこそ、コンパイル時にすべてを終わらせる――それがHaxeを掌握する者の流儀だ。