The more I think about this, the more I think we should expose an `_undelegate` method to hide the implementation there. Implementors of `_undelegate` should know what constitutes a context for that view class and deal according. Since `undelegateEvent` is rarely useful by itself, it should be chainable and that's the only thing it should do, for the actual undelegation, it should delegate to `_undelegate`, which subclasses can override. This preserves the hook's naming convention and leaves room for future addition to `undelegateEvents` while minimizing coupling or common behavior and the details of event delegation.