I was thinking this would work in the reverse way: message_list and message_reader get cursor and they listen on cursor. So it is more about the cards listening and removing event listeners than cursor. cursor is more like a data object, and does not care who talks to it. message_list could call a cursor.setCurrentMessage() when it knows it wants to change the message, and message_reader could just call cursor.next() and cursor.previous() directly. message_list and message_reader would then listen for 'currentMessage' events from cursor.

This would allow other cards or controllers to get a handle on cursor and use it without needing to expand the list of listener-type objects that cursor would have to track.

General note: I am on the fence about using setters. So far if they are used in email, they are more about just an indirection to set some other internal data structure value, and not doing extra fancier work like event emitting. The more work it does, the more likely it will be a .setFoo() kind of function.

Perhaps I am still living in the past on this, so I'm open to other thoughts, particularly if @asutherland has other factors to consider. In the farther future there could be an Object.observe() which will do event emitting anyway, but maybe we wait to see how that shakes out anyway. This is mostly just a signpost message about watching how much a setter does -- if it starts to be more than just internal bookkeeping setting, then it may be better to signal that it is a function doing real work than what might look like a more innocuous set.