PHPのGeneratorをHaxeで制圧する：低レイヤからのアプローチ
Haxeを単なる「クロスコンパイル言語」と呼ぶのは、その真の能力を過小評価している。真のHaxeエンジニアであれば、ターゲット言語のVMが持つメモリ管理や実行モデルをハックし、型安全という枷をはめつつ、ランタイムの深淵に手を突っ込む術を知っているはずだ。
今回は、PHPの強力な武器である「Generator (`yield`)」を、Haxeの `Iterable`/`Iterator` プロトコルに適合させ、型安全に抽象化するテクニックを伝授する。これは単なるラッパーではない。PHPのスタックレスな遅延評価と、Haxeの静的型付けをコンパイルレベルで融合させる試みである。
PHP Generatorの正体とHaxeの懸隔
PHPの `Generator` は、`Iterator` インターフェースを実装する `Traversable` なオブジェクトだ。しかし、Haxe側から見ると、これらは不透明な `Dynamic` であるか、あるいは中身が見えないブラックボックスにすぎない。
Haxeの `Iterator
interface Iterator
function hasNext():Bool;
function next():T;
}
一方、PHPの `Generator` は `current()`, `next()`, `valid()`, `rewind()` といったメソッドを持つ `Iterator` インターフェースを実装している。この「意味論の差異」を埋めるには、抽象型（Abstract Types）を利用したインライン展開が最適解となる。
実装：Abstract Typeによるゼロコスト・ブリッジ
無駄なラッパーオブジェクトの生成はメモリを圧迫し、GCの負荷を高める。我々は、コンパイル時に解決される「抽象型」を用い、PHPのネイティブな `Generator` を直接ラップする。
@:forward
abstract PhpGeneratorIterator
// コンパイル時に型安全なIteratorインターフェースに適合させる
public inline function hasNext():Bool {
return this.valid();
}
public inline function next():T {
var val = this.current();
this.next(); // PHP側のカーソルを進める
return val;
}
// イテレータ自体を返すためのアダプタ
public inline function iterator():PhpGeneratorIterator
return this;
}
}
なぜこの設計なのか
1. `@:forward` の活用: `php.Generator` が持つ他のメソッド（`send()` や `throw()` など）を保持しつつ、`Iterator` プロトコルを静的に付与する。
2. インライン化: コンパイラは、`hasNext()` や `next()` の呼び出しを、直接的なPHPのネイティブメソッド呼び出しに置換する。これは関数呼び出しのオーバーヘッドを排除するための必須テクニックだ。
現場での活用例：Composerパッケージとの共存
既存のPHPライブラリが `yield` を多用している場合、以下のように定義することで、Haxe側からはネイティブなコレクションのように扱える。
class PhpBridge {
// 外部のPHPライブラリが返すGeneratorを想定
public static function fetchLargeDataSet():PhpGeneratorIterator
// コンパイル後はそのままネイティブなGeneratorとして扱われる
return untyped __php__(“some_legacy_lib_generator()”);
}
}
// 利用側
class Main {
static function main() {
var data = PhpBridge.fetchLargeDataSet();
for (item in data) {
trace(item); // 型安全にループ処理が可能
}
}
}
パフォーマンスとセキュリティの深淵
このアプローチの真髄は、「PHPの実行スタックをHaxe側で汚染しない」ことにある。
- 遅延評価の恩恵: 数百万件のデータセットを扱う際、Haxe側で配列にキャストしてはいけない。それはメモリリークを招く愚策だ。この `PhpGeneratorIterator` は、イテレーションの瞬間にのみPHPのランタイムスタックでメモリが確保される。
- 型安全性の担保: Haxeのコンパイラが `Iterator
` としてチェックを行うため、実行時に `mixed` なデータが混入するリスクをコンパイル段階で抑制できる。
注意：セキュリティ研究者への提言
PHPの `Generator` は、`send()` メソッドを介した双方向通信が可能だ。もし外部からの入力をそのまま `yield` に渡すようなライブラリを利用する場合、`PhpGeneratorIterator` を経由する際に必ず型変換（またはバリデーション）を挟むこと。Haxeの `abstract` は単なるメタデータではなく、コンパイル時の防御壁（Gatekeeper）として機能する。
総括
HaxeをPHPターゲットで使う際、ターゲット言語のランタイムを「使いにくいもの」として隠蔽するのではなく、「利用可能な最も強力なエンジン」として再定義する。これが我々アーキテクトがやるべき仕事だ。
今回の実装は、PHPの遅延実行モデルをHaxeの静的システムに「翻訳」する最小にして最強の手段である。言語の境界線で迷子になるな。境界線こそが、最もパフォーマンスを絞り出せる戦場なのだから。