Somewhat. The usual rules of working in a garbage collected language still apply -- references are references, and keeping an event bound to another object is a reference to that object.

`listenTo` and `stopListening` just give you an inverted (and often easier) way to manage the references ... so that you can remove all of the references from the "other" side. For example:

    view.listenTo(model, 'change', view.renderChange);
    view.listenTo(collection, 'add', view.addItem);
    view.listenTo(Backbone, 'initialLoad', view.reinit);

    # ... and then, when you want to get rid of the view:

    view.remove(); 
    # Calls view.stopListening(), removing *all* of the
    # events from "view" bound on all of those different objects.

Note that none of this is necessary if you throw away both sides of the bound event at the same time -- those will still be GC'd as usual. Also, this isn't just for Views. The methods are available on anything that mixes in Backbone.Events.

A comment on the description of listenTo on the Docs page:

> Tell an object to listen to a particular event on an other object. The advantage of using this form, intead of other.on(event, callback), is that listenTo allows the object to keep track of the events, and they can be removed all at once later on.

I had to read this a few times and the given example to see that the convenience comes from tracking events on the listening object side.

Using "object" and "other" for the object variable names makes it a little confusing. I didn't realize the bolded "object" meant the listener object, as opposed to the object being listened to.

Yes -- I struggled for a while with the wording of that. I've you've got a re-phrasing that would make it clearer, I'm all ears.

This explanation actually provides 2 examples, one before the description text and one after. The description refers to the example before:

> listenTo object.listenTo(other, event, callback)

I think changing the naming to be more specific and updating the description names could help out.

   listenTo  observingObject.listenTo(actingObject, event, callback)

One caveat is that this breaks consistency with the other examples in this section (i.e. object.once(...) object.trigger(...)).

Thanks for the explanation. Looks like a useful and nicely minimal addition.

Yes - view.remove() calls "stopListening" - so when you use "listenTo" all listeners should be taken care of.

This doesn't account for any child-views, or views that don't use .remove(), so you'll need to make sure those are taken care of when a view is destroyed. But in most cases, the garbage collection issues that have been seen relating to views & events are taken care of.