Closureのイベントハンドラー：状況わろし

goog.events.EventHandler(component) がまたなんつーか、「イベントハンドラー」という言葉の多義性の新しい例で、イベント処理用のバインディングを行うlisten関数を所有するオブジェクト、ということになる。

いわゆるイベントハンドラー関数とは全然違う。いわゆるイベントハンドラー関数は、listen関数の第三引数に指定される。んで、listen関数は、eh.listen(target, eventType, handler) として使う。ehがClosureのEventHandlerオブジェクトなのだ。んじゃ、listenの第三引数は何と呼ぶか？ イベントリスナーだな。

つまり、Closureにおけるイベントハンドラーとイベントリスナーはまったくの別物。もちろん、DOMの用語ともXMLEventsの用語とも整合しない。XMLEventsのリスナーに近いのがlisten関数。イベントハンドラーのlistenは goog.events.litenの使いやすいラッパーになっている。

• 早わかり イベントモデル → http://d.hatena.ne.jp/m-hiyama/20071206/1196905196

Closureイベントハンドラーは、イベント処理のバインディングを管理する責任主体みいたもので、イベントターゲット（発生源）ともリスナーの所有者とも概念的には別。

さらにややこしいのは、EventHandlerオブジェクトに handler_ というプロパティがあって、これがハンドラーを指している。ええええー、ハンドラーからハンドラーを指すってナニソレ？

EventHandlerオブジェクトは、別なとあるオブジェクトに所有されることがあって、その所有者をhandler_が指している。この所有者もハンドラーと呼ぶのだ、、、、ムムムムム。handler_は、リスナー関数群の所有者であることが多い。

理解を促すスニペット：

/**
 * Stops listening to the events.
 * @private
 */
goog.ui.LabelInput.prototype.detachEvents_ = function() {
  if (this.eventHandler_) {
    this.eventHandler_.dispose();
    this.eventHandler_ = null;
  }
};

さらに悪いニュース：リスナー関数のネーミングは handleXxx （Xxxはイベント名）。ウギャ！