Haxe抽象型（Abstract）がPHPの型安全を救う：プリミティブ型ラップのコスト検証と実践設計
コードレビューをしていて、次のようなコードに遭遇したことはないだろうか。
// どこにでもある「危険な」コード
function getUserData(userId:Int, accountId:Int) { … }
// 呼び出し側で引数を間違えても、コンパイラは何も言わない
getUserData(accountId, userId); // バグの温床
PHPという動的言語のラッパーとしてHaxeを採用するプロジェクトにおいて、最もやりがちな設計ミスがこれだ。データベースの主キー（User ID）、外部APIのUUID、注文ID（Order ID）がすべて単なる `Int` や `String` として扱われていないだろうか？
PHPのネイティブな世界では、これらはすべて `int` や `string` になり、型安全の恩恵はゼロになる。しかし、我々はHaxeを使っている。Haxeの 抽象型（Abstract） を使えば、実行時のオーバーヘッドを完全にゼロに抑えながら、コンパイル時に厳密な型検査を強制できる。
今回は、HaxeからPHPへのトランスパイル機構の裏側を覗きつつ、ゼロコストかつ堅牢なID管理設計をコードレビューの視点で伝授しよう。
—
1. なぜ「普通のクラス」によるラップはPHPで地雷なのか？
型安全性を高めようとして、初心者はつい次のようなクラスを書きがちだ。
// 悪手：普通のクラスによるラップ
class UserId {
public var value(default, null):Int;
public function new(value:Int) {
this.value = value;
}
}
これをHaxeで書いてPHPにトランスパイルするとどうなるか？
Haxeのクラスは、そのままPHPのクラスに変換される。つまり、数千件のレコードを処理するループの中で `new UserId($id)` が呼ばれるたびに、PHPのオブジェクト生成コストとガベージコレクションの負荷が直撃する。PHPにおけるオブジェクトはメモリを食う。パフォーマンスを重視するWebアプリケーションにおいて、これは致命傷になり得る。
2. 救世主：Haxe抽象型（Abstract）のゼロコストマジック
Haxeの `abstract` は、クラスでも構造体でもない。「コンパイル時のみ型をすげ替える、幻影のラッパー」だ。
// 善手：抽象型によるプリミティブのラップ
abstract UserId(Int) {
public inline function new(value:Int) {
this = value;
}
@:to
public inline function toInt():Int {
return this;
}
@:from
public inline function fromInt(value:Int):UserId {
return new UserId(value);
}
}
このコードがPHPにトランスパイルされたとき、何が起きるか？
`UserId` というクラスやオブジェクトはPHPのコード上から完全に消滅する。
Haxeコンパイラは、`UserId` 型の変数をすべてただの生の `int`（PHPのプリミティブ）として出力する。つまり、実行時にはオブジェクトの生成コストが一切発生しない。これが「ゼロコスト・抽象型」の真髄だ。
—
3. 【実践】プロダクションコードで使う堅牢なID設計パターン
実際のWebアプリケーション開発でそのまま使える、型安全なID管理モジュールを組み立ててみよう。ここでは、ドメイン駆動設計（DDD）の価値オブジェクト（Value Object）の思想を取り入れる。
package domain.model;
/
- ユーザーIDを表す抽象型
/
abstract UserId(Int) {
public inline function new(value:Int) {
if (value <= 0) {
throw 'Invalid UserId: $value';
}
this = value;
}
@:to
public inline function toInt():Int {
return this;
}
@:from
public static inline function fromInt(value:Int):UserId {
return new UserId(value);
}
// 文字列化の演算子オーバーロード
@:to
public inline function toString():String {
return Std.string(this);
}
}
/
- 注文IDを表す抽象型（Intベースだが、UserIdとは絶対に混ざらない）
/
abstract OrderId(Int) {
public inline function new(value:Int) {
if (value <= 0) throw 'Invalid OrderId: $value';
this = value;
}
@:to public inline function toInt():Int return this;
@:from public static inline function fromInt(value:Int):OrderId return new OrderId(value);
}
この設計が美しい理由
1. コンパイルエラーによる事故防止: `UserId` を要求される箇所に `OrderId` を渡すと、Haxeコンパイラが即座にビルドを止める。PHPにバグを持ち込む余地を与えない。
2. PHPネイティブとの親和性: `@:to` や `@:from`、そして `inline` の組み合わせにより、PHP側では単なる `int` として高速に動作しつつ、Haxeの静的解析の恩恵を100%受けられる。
—
4. PHPターゲット特有の罠と注意点
Haxeの抽象型は強力だが、PHPへトランスパイルする際には「Haxeの型システム」と「PHPの動的性質」の境界線で注意すべき点がある。
① 外部からのデータ入力（$_GETやPDOの結果）の境界
データベースから取得したデータや、HTTPリクエストのパラメータは、最初は単なる `Int` や `String` である。これらを抽象型に変換する境界（Anti-Corruption Layer）では、必ず明示的なキャストか `@:from` を経由させる必要がある。
class UserRepo {
public function findById(id:UserId):User {
// $id は実体としては Int なので、PHPのPDOプレースホルダーにもそのまま渡せる
var rawSql = “SELECT FROM users WHERE id = ?”;
// …
}
}
// 呼び出し側の境界
var inputId:Int = Std.parseInt(php.Web.getParams().get(“id”));
// ここで自動的（あるいは明示的）に UserId に変換される
var userId:UserId = inputId;
② ジェネリクスやJSONシリアライズ時の挙動
抽象型を `haxe.Json.stringify()` に渡す場合、ベースとなるプリミティブ型に正しくフォールバックするか確認すること。基本的には `@:to` が適切に作用するため問題ないが、複雑なメタデータを付与する場合は `ToJSON` メタデータの活用を検討せよ。
—
5. まとめ：コードレビューで明日から使えるチェックリスト
チームのメンバーが次のようなコードを書いているを見つけたら、すぐにこのルールを適用させよう。
- [ ] 「ただのIntやStringのID」を関数の引数にバラバラと渡していないか？
→ 意味のある `abstract` でラップし、ドメインの意図を型に語らせろ。
- [ ] ラップのために無駄な `class` を作っていないか？
→ 実行時オーバーヘッドを避けるため、必ず `abstract(T)` と `inline` を使ったゼロコスト抽象型にリファクタリングしろ。
- [ ] 型変換の境界が明確か？
→ 外部入力（DB/API）と内部ドメインの境界を `@:from` / `@:to` で美しく繋ぎ込め。
Haxeの抽象型を制する者が、Haxe-PHPアーキテクチャを制する。型安全の盾を手にし、PHPの実行パフォーマンスを落とさずに、モダンで堅牢なWebアプリケーションを構築してほしい。