【入門編】Hackの『Readonly』属性の真価：不変データ構造がHHVMの最適化と型安全性に与える相乗効果 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Hackを掌握せよ：`readonly`が解き放つ「不変性」とHHVM最適化の深淵

こんにちは。Hackの深淵を覗き込み、その静的型システムの美しさに魅せられた皆さん。

今日は、Hackという言語が持つ「静的型付けの厳格さ」と「HHVMの実行効率」の接点において、最もエレガントな役割を果たす`readonly`属性について語りましょう。

よく「readonlyは値を変更させないためのガードレールでしょ？」と思われがちですが、それは氷山の一角に過ぎません。HackのコアエンジンであるHHVMにとって、`readonly`は「このメモリ領域は、コンパイル時以降、二度と書き換えられない」という究極の最適化ヒントなのです。

ここをマスターすれば、あなたの書くコードは単に「安全」なだけでなく、「爆速」へと進化します。

—

1. `readonly`の本質：ただの保護機能ではない

通常のプログラミングにおいて、変数は「いつでも書き換えられるもの」として扱われますよね。しかし、HHVMのJITコンパイラは、コードの隅々まで「どこで値が変わったか」を追いかける必要があります。

もし、あるプロパティが一度定義されたら二度と変わらないと保証されていたらどうでしょうか？

型チェッカー: 変更の追跡コストがゼロになる。
HHVM JIT: 読み込みをキャッシュし、メモリアクセスを最小化できる。

これが`readonly`の真価です。

基本的な使い方

<<__ConsistentConstruct>>
class User {
// readonlyを付与することで、初期化時以外は書き込み不可を保証
public readonly string $username;
public readonly int $id;

public function __construct(string $username, int $id) {
$this->username = $username;
$this->id = $id;
}
}

// インスタンス化
$user = new User(“HackMaster”, 1);

// $user->username = “NewName”; // ここでHackの型チェッカーが即座にエラーを吐きます

—

2. なぜ`readonly`がHHVMの最適化を加速させるのか

HHVMのアーキテクチャでは、オブジェクトのフィールドはメモリ上の特定のオフセットに配置されます。通常、プロパティが変更される可能性がある場合、JITは「書き込みが発生した後に、その値をキャッシュしても安全か？」という複雑な判断を常に迫られます。

`readonly`が付与されていると、HHVMは以下のような戦略をとります：

1. レジスタ割り当ての最適化: 頻繁にアクセスされる値であれば、それをメモリから読み直す代わりに、CPUのレジスタに永続的に保持し続ける判断をします。
2. インライン化の障壁除去: 書き換えの可能性があるメソッド呼び出しは、JITのインライン化（関数の中身を呼び出し元に埋め込む最適化）を妨げることがありますが、`readonly`はその制約を取り払います。

つまり、「不変性は性能の源泉」なのです。

—

3. 陥りやすい罠：ここだけは気をつけよう

初学者がよくやってしまうのが、`readonly`と「深い不変性（Deep Immutability）」の混同です。

注意すべきポイント

class Container {
// プロパティ自体はreadonlyですが、中の配列は書き換え可能！
public readonly vec $values;

public function __construct(vec $values) {
$this->values = $values;
}
}

$c = new Container(vec[1, 2, 3]);
// $c->values = vec[4]; // これはエラー（readonlyプロパティの再代入不可）
// $c->values[] = 4; // これもエラー（readonlyはプロパティの書き換えを禁止）

重要な教訓:
`readonly`は「プロパティ参照（`$this->prop`）」を保護しますが、その先にあるオブジェクトやコレクションの内容までを強制的に不変にするわけではありません（これには`immutability`の概念が別途必要です）。まずは、プロパティ単体から`readonly`を徹底する癖をつけましょう。

—

4. 現場で「勝てる」コードを書くために

現場でHackを使いこなすコツは、「デフォルトで`readonly`を検討し、必要であれば解除する」という逆転の発想です。

DTO（データ転送オブジェクト）には必ず付ける: 外部から受け取ったデータを保持するクラスは、最初から`readonly`にすべきです。
状態管理を分離する: 「状態を変えるクラス」と「データを保持するクラス」を分ける設計にすることで、HHVMが最適化しやすい粒度のコードが自然と生まれます。

—

まとめ：Hackを掌握するということ

`readonly`を使いこなすことは、単なる文法の習得ではありません。それは、「このデータは今この瞬間から、世界に対して厳格な責任を持つ」という宣言を、コンパイラと共有することです。

型チェッカーがあなたのコードを守り、HHVMがそのコードを光速で実行する。その体験こそが、Hackという言語の最大の醍醐味です。

ここをクリアしたあなたは、もうHackの初学者ではありません。次はぜひ、`readonly`と`immutability`の境界線、そしてHackが提供する`Readonly Collection`の世界へ一歩踏み出してみてください。

それでは、また次回の深淵でお会いしましょう。ハッピー・ハッキング！