anchor.diff:  <%= File.read("examples/include_observer.rb") %>
   ```
   
  -*So including `Observer` automatically handles the dispatching of events from `#call` to the various `#on_*` methods?*
  +*So including `Observer` automatically handles the dispatching of events from `#call` to the various `#on_` methods?*
   
   Yes, exactly. And through some metaprogramming, it is able to do this in a way that is just as performant as a hand-written case statement.
   
   *How do you know it's that fast?*
   
   You can run the proof-of-concept benchmark for yourself! It's in the `scripts` directory.
  +
  +=== Managing subscription lifetime
  +
  +*You know, it occurs to me that in the `Poem` example, it really doesn't make sense to have an `HtmlFormatter` plugged into a `Poem` forever. Is there a way to attach it before the call to `#recite`, and then detach it immediately after?
  +
  +Of course. All listener registration methods return a `Subscription` object which can be used to manage the subscription of an observer to emitter. If we wanted to observe the `Poem` for just a single recital, we could do it like this:
  +
  +```ruby
  +p = Poem.new
  +f = HtmlFormatter.new
  +subscription = p.events.attach(f)
  +p.recite
  +subscription.cancel
  +```
  +
  +*OK, so I just need to remember to `#cancel` the subscriptions that I don't want sticking around.*
  +
  +That's one way to do it. But this turns out to be a common use case. It's often desirable to have observers that are in effect just for the length of a single method call.
  +
  +Here's how we might re-write the "poem" example with event subscriptions scoped to just the `#recite` call:
  +
  +```ruby
  +<%= File.read("examples/scoped_subscription.rb") %>
  +```
  +
  +In this example, the `HtmlFormatter` is only subscribed to poem events for the duration of the call to `#recite`. After that it is automatically detached.
  +
  +=== Replacing return values with events
  +
  +*This is interesting. I can see this being useful for more than just traditionally event-generating objects*
  +
  +Indeed it is! This turns out to be a useful pattern for any kind of method which acts as a "command".
  +
  +TODO...
   
   ## Installation
   
  
positive.code: 
  Well, the most important feature it has is *named event types*. Instead of a single "update" event, events have symbolic names. Observers can choose which events they care about, and ignore the rest.
  
  *What exactly is a "observer"? Is it a special kind of object?*
  
  Not really, no. Fundamentally a observer is any object which responds to `#call`. The most obvious example of such an object is a `Proc`. Here's an example of using a proc as a simple observer:
  
negative.code: 
  For convenience, the event name, source, and arguments are all bundled into an `Event` object before being disseminated to observers.
  
  === Making an object observable
  
  *OK, say I have an object that I want to make observable. How would I go about that?*
  
  Well, the no-magic way might go something like this:
  