generate

呼び出し回数の最適化では、リスナがイベントの数を意識することがなくなると説明されています。

確かにsubscribeを使えばリスナの呼び出し回数の最適化の余地はありますが、イベントを発生させる側がn個のイベントを発生させている以上、イベント発生のオーバーヘッドはあります。

generateメソッドを使えば、generateを使った例のように、イベント発生ではなくストリームのような構文になっているため、複数のイベントをまとめることができます。

generateメソッドに渡されたブロックは、他のプラグインでsubscribeや通常のイベントリスナ（on_???）でリスナが登録されるまで実行されません。

generateを使った例の user_stream メソッドを呼び出すとSNSのサーバにHTTPコネクションを確立するとしましょう。appearイベントを受け取るプラグインが存在しなければ、わざわざインターネットから投稿を取得して居るにも関わらず、それをすべて捨てていることになります。

そこでgenerateを使った例のような実装をすれば、appearイベントが購読されて初めて接続するようになります。実際にこの仕組みはMastodonプラグインに利用されています。あらゆるデータがあらゆるストリームでいつでも受け取れるように見えるにも関わらず、実際には必要とされている情報しかMastodonサーバから取ってこないようになっているのです。

普通、そのような最適化をするなら、イベントが購読されているか常に確認し続け、購読状況に応じてサーバに接続するような実装をする必要があるでしょう。generateメソッドを使えば、そのような判断をPluggaloidに一任できます。

subscribeで、 event-slug と rest が完全に一致するリスナが一つでも登録されたら、ブロックを実行します。

on_ event_slug でリスナが定義されると、 rest の内容に関わらず、即座にブロックが実行されます（ rest が一致したと見做して処理をします）。

条件を満たすsubscribeが2つ以上になってもブロックは最初の一度しか実行されませんが、subscribeが解除されて0になると、ブロック内で定義された全てのイベントリスナ等が解除されます。

解除されるものは以下の通りです。

ストリームに一つ値を追加します。generateメソッドに指定したストリーム引数以外の引数を伴ってイベントが発生します。

ストリームに2つ以上の値を同時に追加します。generateメソッドに指定したストリーム引数以外の引数を伴ってイベントが発生します。一度にたくさんのオブジェクトを追加したい場合、self << object → selfよりこちらのほうが効率的です。