Hackの非同期を「掌握」する：Awaitable
Hackにおいて `async` は単なる「非同期糖衣構文」ではない。HHVMの実行モデルにおいて、それは型システムとランタイムが握手して実現する、「未来の値を確実に手繰り寄せるための契約」だ。
多くの言語で非同期処理は「Promiseの連鎖」という迷宮に陥りがちだが、Hackの `Awaitable
—
1. Awaitable は「値の箱」ではない、「計算の約束」だ
まず認識を改めろ。`Awaitable
型チェッカー（HHVM Typechecker）は、`async` 関数を呼び出した瞬間に、その戻り値を `Awaitable
2. 現場で「死なない」コード設計：コンポーネント指向の非同期設計
実務でよく見る悪手は、「非同期の汚染」を考慮せず、同期関数の中に非同期処理を混入させることだ。これはコードベースの癌になる。
美しいプロダクションコードの例
以下のコードを見てほしい。外部APIとの通信を抽象化し、型安全に複数のタスクを並列実行するパターンだ。
namespace App\Infrastructure;
final class UserClient {
// 戻り値は常に Awaitable
public async function fetchUserById(int $id): Awaitable
// 実際にはHHVMの非同期I/Oがここで発火する
return await $this->httpClient->getAsync(‘/users/’.$id);
}
}
final class UserAggregator {
public function __construct(private UserClient $client) {}
public async function getAggregatedData(vec
// 複数のAwaitableを生成し、並列実行の準備をする
$tasks = vec[];
foreach ($ids as $id) {
$tasks[] = $this->client->fetchUserById($id);
}
// Awaitableを効率的に結合し、HHVMスケジューラに一括委譲する
// ここで型は vec
return await Vec\from_async($tasks);
}
}
なぜこの設計が堅牢なのか？
- 型推論の透過性: `Vec\from_async` は `Traversable
- HHVMの並列実行: `await` を個別に書くのではなく、`Vec\from_async` を使うことで、HHVMは複数のI/O待機を単一のイベントループで効率的に処理できる。
—
3. パフォーマンスの罠：Awaitableの不必要な「待ち」
パフォーマンス上の注意点として、「シリアルなawaitの連鎖」は避けるべきだ。
// 悪い例：完全に同期的な実行を非同期でやっているだけ
$user = await $client->fetchUserById(1);
$posts = await $client->fetchPostsByUser($user->id); // 前の結果を待つ必要があるなら仕方ないが…
もし依存関係のないタスクなら、「Awaitableを先に作成し、最後にまとめてawaitする」のがHHVMの真価を引き出す作法だ。Awaitableを生成した時点では、HHVMは裏で既にI/Oをスケジューリングしている。`await` はその「結果を受け取るポイント」に過ぎない。
4. チーフアーキテクトからの助言：Strict Modeの魂
Hackの `Strict Mode` は、単なる制約ではない。「開発者が思考をサボる余地を奪い、システムの整合性を維持するための自動防衛システム」だ。
- null許容型との付き合い方: `?Awaitable
` は極力避けろ。非同期処理が「存在しない」可能性があるなら、`Awaitable - 型チェッカーを信じろ: もし型チェッカーがエラーを吐くなら、それはあなたのコードが「非同期の整合性を損なう可能性」を秘めているという、コンパイラからの慈悲深い警告だ。`suppress`（抑制）で隠すな、設計を修正しろ。
—
まとめ：非同期処理の頂点を目指せ
Hackの `Awaitable
君たちが書くコードの一行一行が、この強力な型システムによって守られていることを忘れるな。次にコードレビューをする際は、単に動くかではなく、「そのAwaitableの生成と消費のタイミングが、HHVMのスケジューラにとって最も効率的かつ型安全であるか」を問い直してほしい。
それが、Hackを掌握するということだ。