コードレビュー開始：HaxeからPHPへのトランスパイルにおけるメソッドディスパッチの罠
プロダクションコードのレビューをしていると、Haxeの強力なクロスプラットフォーム性に惚れ込み、ターゲット言語（今回はPHP）のランタイム特性を無視して記述されたコードに直面することがある。
「Haxeで書けばどこでも動く」――それは事実だ。しかし、「どこでも同じパフォーマンスで動く」とは一言も言っていない。
特にHaxeからPHPへのトランスパイルにおいて、`static` メソッドとインスタンスメソッドの選択を誤ることは、Zend Engineの実行コスト（OPcacheの効率、メソッドキャッシュのヒット率、オブジェクトのプロパティルックアップのオーバーヘッド）に直結する。
今回は、Haxeのクラス構造がPHPにどのようにマッピングされるかを解剖し、高負荷なWebアプリケーションで確実に差が出るメソッドディスパッチの最適化設計を伝授する。
—
1. 脳内トレース：HaxeコードはPHPでどう姿を変えるか？
まず、Haxeのコンパイラが吐き出すPHPコードの現実を直視しよう。
Haxeにおける通常のインスタンスメソッド呼び出しと静的メソッド呼び出しが、PHP側でどのような構造に変換されるのかを比較する。
Haxeのソースコード
class DispatchBenchmark {
public function new() {}
// インスタンスメソッド
public function instanceAdd(a: Int, b: Int): Int {
return a + b;
}
// 静的メソッド
public static function staticAdd(a: Int, b: Int): Int {
return a + b;
}
}
変換されるPHPコード（概念的出力）
HaxeのPHPターゲットランタイムは、厳密な型安全性やHaxe特有のオブジェクト指向挙動（動的プロパティの許容など）を維持するため、いくつかのヘルパー構造を挟んで出力される。
class DispatchBenchmark {
public function __construct() {}
// インスタンスメソッド
public function instanceAdd($a, $b) {
return $a + $b;
}
// 静的メソッド
public static function staticAdd($a, $b) {
return $a + $b;
}
}
「あれ？PHPでもそのまま `->` と `::` になるだけじゃないか」と思ったなら、PHPの実行モデルを過小評価している。
なぜインスタンスメソッドはコストがかかるのか？
1. インスタンス生成のオーバーヘッド: インスタンスメソッドを呼ぶためには、原則として `new DispatchBenchmark()` が必要であり、Zend Engine上でZVAL（変数コンテナ）とオブジェクトハンドラの割り当てが発生する。
2. $this コンテキストの解決: インスタンスメソッドの内部では、常に `$this` ポインタのバインディングとスコープ解決が行われる。
3. 動的ディスパッチ（ポリモーフィズムの代償）: Haxeではデフォルトでクラスやメソッドが `final` でない限り、サブクラスでのオーバーライドを考慮した仮想メソッドテーブル（vtable的な仕組み）のルックアップコスト、あるいはPHPの実行時メソッドバインディングのコストがわずかに上乗せされる。
一方、`static` メソッドはコンパイル時にシンボルが完全に静的解決され、`$this` のアロケーションも不要。Zend Engineはこれを極めて効率的に直接コール（`ZEND_INIT_STATIC_METHOD_CALL`）できる。
—
2. 実務で使える設計パターン：抽象型（Abstract Types）と静的メソッドの融合
「パフォーマンスのために全てを静的メソッドにしろ」というのは、オブジェクト指向を放棄した暴論だ。保守性は一瞬で崩壊する。
我々が取るべきアプローチは、「状態を持たないユーティリティやドメインサービスは `static` または `HaxeのAbstract（抽象型）` に閉じ込め、ポリモーフィズムが必要な箇所のみインスタンスを使う」という明確な境界線引きだ。
以下に、実務の現場でそのまま使える、堅牢かつ極限まで最適化されたコンポーネント設計のプロダクションコードを示す。
プロダクションコード例：高速演算パイプライン
package com.enterprise.math;
/
- 状態を持たない純粋関数群。
- すべて static メソッドとして定義し、PHPトランスパイル時に
- インスタンス生成コストを完全にゼロにする。
/
class MathPipeline {
/
- バッチ処理における安全な加算処理。
- インライン展開（@:inline）を強制し、PHP側での関数呼び出しオーバーヘッドすら排除する。
/
@:inline
public static inline function safeAdd(a: Float, b: Float): Float {
return (Math.isNaN(a) ? 0.0 : a) + (Math.isNaN(b) ? 0.0 : b);
}
/
- 複雑な計算ロジック。
/
public static function calculateTax(amount: Float, rate: Float): Float {
if (amount <= 0) return 0.0;
return Math.fround(amount rate 100) / 100;
}
}
/
- 抽象型（Abstract）を活用したゼロコストの型安全ラッパー。
- PHPにトランスパイルされた際、このラップ構造は完全に消滅し、
- 単なるプリミティブ値（Float）として処理されるため、オブジェクトのインスタンス化コストは皆無。
/
abstract Price(Float) {
public inline function new(value: Float) {
this = value < 0 ? 0.0 : value;
}
@:to
public inline function toFloat(): Float {
return this;
}
@:op(A + B)
private inline function add(rhs: Price): Price {
return new Price(this + (rhs : Float));
}
}
/
- 実際のビジネスロジックを担うサービスクラス。
- 依存性注入（DI）やインターフェースによる抽象化が必要なため、
- ここであえてインスタンスメソッドを採用する。
/
class OrderProcessor {
private var taxRate: Float;
public function new(taxRate: Float) {
this.taxRate = taxRate;
}
/
- インスタンスメソッド：状態（taxRate）に依存するため、staticにはできない。
/
public function processOrder(basePrice: Price): Price {
var rawPrice: Float = basePrice;
var tax = MathPipeline.calculateTax(rawPrice, this.taxRate);
return new Price(rawPrice + tax);
}
}
—
3. コードレビューの鉄則：いつ `static` を選び、いつインスタンスを選ぶべきか
チームメンバーから「このメソッドはどこからもプロパティを参照していないのに、なぜインスタンスメソッドにしているのか？」と問われたとき、明確に答えられなければならない。
以下の基準をチームのコーディング規約として定めてほしい。
✅ `static` メソッド（または `inline static`）を採用すべきケース
1. ステートレス（状態を持たない）である: クラス内のフィールド（プロパティ）を一切読み書きしない。
2. 純粋関数（Pure Function）である: 入力が同じであれば常に出力が同じ。
3. ヘルパー・ユーティリティ・ファクトリ: オブジェクトのライフサイクル管理に関与しない処理。
4. 極限のパフォーマンスが求められるループ内処理: PHPの関数呼び出しスタックを少しでも軽くしたい場合（`@:inline` と組み合わせることで真価を発揮する）。
✅ インスタンスメソッドを採用すべきケース
1. ポリモーフィズム（多態性）が必要: インターフェースを実装し、DIコンテナ等で切り替える必要がある場合。
2. 内部状態（State）を持つ: オブジェクトが生成されてからのライフサイクルにおいて、プロパティの値を変更・保持する場合。
3. フレームワークのライフサイクルとの統合: PHP側のフレームワーク（SymfonyやLaravelなど、Haxeからバインディングする際）のコントラクトに準拠する必要がある場合。
—
チーフアーキテクトからの総括
Haxeのクロスプレーンな能力は強力だが、出力先であるPHPのランタイム特性（Zend Engine）を無視したコードは、スケールするWebアプリケーションにおいて必ずボトルネックになる。
「なんとなく `new` してインスタンスメソッドを呼ぶ」という惰性を断ち切れ。
Haxeのマクロとインライン展開、そして静的メソッドの特性を完璧に理解し、「実行時に無駄なオブジェクトを作らない設計」をコードで証明すること。それこそが、真のHaxeマスターであり、優れたテクニカルリードの仕事である。
次のプルリクエストでは、不要なインスタンス化が排除された美しいコードがあがってくることを期待している。