こんにちは！Hack言語の世界へようこそ。フルスタックエンジニアの先輩として、今日は皆さんが必ず直面する「Nullableの迷宮」を鮮やかに突破する極意をお伝えしますね。
他の言語（PHPやTypeScriptなど）からHackに入った開発者が、最初に頭を悩ませるのが「Strict Mode（厳格モード）」におけるNullable型の伝播（プロパゲーション）です。
「データベースから取ってきた値だから、もしかしたら`null`かもしれない…」
そう思って`?string`型として定義した途端、あちこちのメソッド呼び出しで型チェッカーに怒られてしまい、コードが`if ($val !== null)`の要塞になってしまった経験はありませんか？
今回は、連鎖的な型エラーを華麗に回避し、HHVMの型チェッカーがニヤリと微笑むような「安全で美しい設計術」を一緒に紐解いていきましょう。ここをクリアすれば、あなたのHackのスキルは間違いなく一段上のステージに上がりますよ！
—
1. なぜNullableは「伝染」するのか？（基本のおさらい）
Hackでは、デフォルトで`<<__Strict>>`モードを推奨しています。ここでは曖昧な型は一切許されません。
例えば、ユーザーのプロフィール情報を取得するコードを考えてみましょう。
<<__STRICT>>
namespace App\Core;
class UserProfile {
public function __construct(public ?string $bio) {}
}
function get_user_bio(?UserProfile $user): ?string {
// $user が null の可能性があるため、そのまま ->bio にアクセスすると型エラーになります
return $user->bio;
}
このコードを型チェッカーに通すと、次のようなエラーが発生します。
> Type checker error: The property `bio` is undefined on an object of type `?UserProfile`
「`?UserProfile`（Nullable）なのだから、中身の`bio`を取り出そうとしたら、オブジェクト自体が`null`かもしれないよ！」と、型チェッカーが身を挺してバグを防いでくれているわけですね。
これを素直に解決しようとすると、コードはこうなります。
function get_user_bio_naive(?UserProfile $user): string {
if ($user === null) {
return “”;
}
if ($user->bio === null) {
return “”;
}
return $user->bio;
}
…なんだか冗長ですよね。実務ではこれが何重にも連鎖し、コードベース全体が`null`チェックのボイラープレートで埋め尽くされてしまいます。これが「Nullable伝播の罠」です。
—
2. 【設計術1】Maybeモナド的アプローチ：早期リターンとガード節の徹底
連鎖的なエラーを防ぐための第一歩は、「異常系や空（null）のケースをコードの最上流でマニュアル処理し、メインストリームを非Nullableの世界に引き戻す」ことです。
HHVMの型チェッカーは、スコープ内の制御フロー解析（Control Flow Analysis）が非常に優秀です。これを利用して、以下のようにガード節を記述します。
<<__STRICT>>
namespace App\Core;
class UserProfile {
public function __construct(public string $bio) {} // ここはあえて非Nullableに！
}
function render_bio(?UserProfile $user): string {
// 【ガード節】ここで null を完全に弾く
if ($user === null || $user->bio === “__EMPTY__”) {
return “プロフィールは未設定です。”;
}
// この行以降、型チェッカーは $user を 「絶対に入っている UserProfile」 として扱う
return “自己紹介: “.$user->bio;
}
ポイント
オブジェクトの生成段階（コンストラクタなど）で、`null`をそのまま持たせるのではなく、デフォルト値（空文字や専用のプレースホルダー）に正規化してしまうのが、Hackにおける極上の設計パターンの一つです。これにより、ビジネスロジック層へ`null`が伝播するのを根元から断つことができます。
—
3. 【設計術2】Nullableチェーンを断ち切るヘルパー関数の活用
どうしても外部APIやレガシーなデータベースから`?string`や`?int`が返ってくる場合はどうすればよいでしょうか？
ここで、Hackのジェネリクス（Generics）を活かした「安全なフォールバック関数」を用意するのがプロの技です。
<<__STRICT>>
namespace App\Utils;
class TypeSafe {
/
- Nullableな値から安全にデフォルト値を取り出す
/
public static function unwrapOr
if ($value === null) {
return $default;
}
return $value;
}
}
これを使うと、連鎖しがちなプロパティへのアクセスも次のようにスッキリと記述できます。
<<__STRICT>>
namespace App\Core;
use namespace App\Utils;
class Settings {
public function __construct(public ?string $theme) {}
}
function get_active_theme(?Settings $settings): string {
// 設定がnull、あるいはテーマがnullなら “default” を返す
// Nullableの連鎖をたった1行で安全に解決！
return Utils\TypeSafe::unwrapOr(
$settings?->theme,
“default”
);
}
ここで使われている `?->` （null安全演算子）と `unwrapOr` の組み合わせは、Hackの静的解析の恩恵を最大限に受けつつ、コードの可読性を爆発的に高めてくれます。
—
4. HHVMの型チェッカーの裏側：なぜこれが最適なのか？
裏側で動いているHHVM（HipHop Virtual Machine）のJITコンパイラと型チェッカーは、コードが「どの時点で確実に非Nullableになったか」を厳密に追跡しています。
中途半端に`null`を許容したままコードの深い層まで値を渡してしまうと、HHVM側でも最適化の余地（Type Specialization）が狭まり、実行時オーバーヘッドや不要な分岐命令が増える原因になります。
つまり、「型チェッカーに怒られないようにする工夫」は、そのまま「HHVMが高速に実行できるコードを書く工夫」に直結しているのです。型チェッカーは私たちの敵ではなく、最高のパフォーマンスを引き出すための最高の相棒なんですよ。
—
おわりに
今回は、Nullable型がコード全体に伝播するのを防ぎ、型エラーを最小限に抑えるための設計術を解説しました。
1. ガード節で最上流に `null` をとどめる
2. オブジェクト内では可能な限り非Nullableな初期値をデザインする
3. ジェネリクスを使ったユーティリティで安全にアンラップする
ここをマスターすれば、Hackの厳格な世界でも息苦しさを感じるどころか、揺るぎない安心感の中で軽快にコードを書けるようになります。
型チェッカーからのエラーメッセージは、あなたのコードをより美しく洗練させるための「優しいアドバイス」です。一つひとつクリアして、Hackを完全に手なずけていきましょう！
それでは、次回の記事もお楽しみに！