Hackの深淵：`readonly`がもたらす「予測可能な状態」の支配術
Hackの型システムを単なる「IDEの補完を助けるツール」だと思っているなら、今すぐ考えを改めるべきだ。我々が構築した`readonly`修飾子と厳格な型推論は、HHVMのJIT最適化と表裏一体であり、メモリ安全性と並行処理の正当性を担保するための「強制力」そのものである。
大規模なWebアプリケーションにおいて、バグの温床の9割は「予期せぬ状態遷移」だ。関数に渡したオブジェクトが、背後で別のプロセスや非同期処理によって書き換えられている——そんな悪夢を、コンパイル時に葬り去るのが`readonly`の本質である。
—
1. なぜ`readonly`が必要なのか：不変性の強制による防御的設計
多くのエンジニアは「値を書き換えないように気を付ける」という精神論で設計を行うが、それは脆弱だ。Hackの`readonly`は、言語仕様として「特定のプロパティは一度初期化されたら二度と書き換わらない」ことを保証する。
これにより、以下のメリットが生まれる。
- 推論の局所化: ある変数が`readonly`であれば、そのプロパティの値は、コードのどの地点においても初期化時の状態を保持していることが保証される。
- キャッシュの安全性: 不変なオブジェクトは、スレッド間やリクエスト間での共有を極めて安全に行える。
- JITの最適化: HHVMのJITコンパイラは、値が不変であることを検知すると、読み込み時のチェックを省略し、レジスタへの割り当てを積極的に行うため、実行速度が向上する。
—
2. 実践：保守性の高いプロダクションコード・パターン
単に`readonly`を付けるだけでは不十分だ。重要なのは「ドメインモデルの境界をどう設計するか」にある。以下のコードは、APIレスポンスのDTO（Data Transfer Object）を定義する際、副作用を排除する典型的なパターンだ。
namespace App\Domain;
/
- ユーザーの決済情報を保持する不変DTO
- readonlyプロパティにより、一度生成されたら改竄不可能であることを保証する
/
final class PaymentTransaction {
// readonlyプロパティはコンストラクタでのみ代入可能
public function __construct(
public readonly string $transactionId,
public readonly float $amount,
public readonly DateTimeImmutable $createdAt,
) {}
// 状態を変更したい場合は、必ず新しいインスタンスを返す（Witherパターン）
public function withAmount(float $newAmount): this {
return new self(
$this->transactionId,
$newAmount,
$this->createdAt,
);
}
}
// 利用例
<<__EntryPoint>>
function main(): void {
$tx = new PaymentTransaction(‘tx_001’, 1000.0, new DateTimeImmutable());
// $tx->amount = 2000.0; // <- ここで型チェッカーがエラーを吐き、コンパイルすら通さない // 変更が必要な場合は明示的に新しいインスタンスを作成する $newTx = $tx->withAmount(2000.0);
echo “Original: {$tx->amount}, New: {$newTx->amount}\n”;
}
なぜこの設計が美しいのか
1. 副作用の排除: `withAmount`メソッドを通すことで、変更の意図がコード上で明確になる。
2. バグの早期発見: `readonly`の制約を破るコードは、HHVMの型チェッカーが静的に弾くため、実行時エラーを未然に防げる。
3. 可読性: プロパティにアクセスした際、それが「どこかで書き換えられるリスク」を考慮する必要がなくなる。
—
3. パフォーマンスと設計上の注意点
`readonly`の活用において、一つだけ注意すべきことがある。「不変オブジェクトを過度に生成しすぎない」ということだ。
Hackにおいて、不変オブジェクトの生成コストは極めて低いが、ホットパス（非常に頻繁に実行されるループ内など）で大量のオブジェクトを生成・破棄すると、GC（ガベージコレクション）の負荷が高まる可能性がある。
- 基本戦略: ドメインモデルやAPIの境界では`readonly`を多用し、厳格さを優先する。
- 例外: 非常に高速な計算が必要な一時的データ構造については、スコープを関数内に限定し、ライフサイクルが明確な一時的な変数（`shape`型など）を活用する。
—
結論：Hackの支配者たれ
`readonly`は、あなた自身を縛るためのものではない。あなたの書いたコードが、チームの誰によって、どのようなタイミングで呼ばれても「期待通りに動作する」という圧倒的な安心感を買うための投資だ。
コードレビューで`readonly`を強制せよ。型チェッカーを自身の右腕として扱え。それこそが、HHVMという強力なエンジンを最大限に活用し、堅牢なプロダクション環境を構築するための唯一の道である。
次は、`readonly`と非同期処理（`Awaitable`）の組み合わせによる、競合状態（Race Condition）の完全な排除について語るとしよう。準備はいいか？