@dgeb the concern is that the reserved API for Route is way more likely to overlap with desirable event names, e.g. enter, activate, exit, etc., so it’s more risky to suddenly have .send search for methods defined directly on the Route.
FWIW, there was a time (router v1) when child routes/states were defined as properties of their parent states, and this understandably did causing lots of namespace conflicts as child state/route names conflicted with event names, but since router v2, this is way less of a concern since subroutes are no longer defined right on the route. But I think the memory of these namespace clashes might be persisting in the present debate.
With respect to name collisions, I agree they have been rare in my Ember experience. So that is less my concern than this: As framework maintainers, any addition to the public API of Controller, ObjectController, ArrayController, or Route (including via mixins like Enumerable) would be a breaking change. From a post-1.0 semantic versioning perspective, would we have to treat any public API addition on those classes as a major version increment?
Really good point. But we’ve got the same problem with helper methods defined on controllers etc. that JavaScript code uses. A lot of controllers probably have save() methods on them. That “prevents” Ember from ever having a core method called save() on controllers.
I’m not sure what a good way to avoid this issue would be. Except to use _ prefix for all private methods. But even then, a user might define his own private method on a controller subclass which accidentally overrides the superclass’ method. But don’t all frameworks where users are supposed to inherit from core classes have this problem?
The only way to fully avoid this issue would be to use the events hash as the exclusive way to define events, as it currently is in routes, and to bring this to controllers as well.
However, the events hash’s isolation from OO inheritance that provides that safety also makes it annoying to work with in the context of the Ember object model.
It’s this tradeoff that @stefan.penner’s gist is trying to address. It lets the app developer determine the tradeoff between isolation from the inheritance hierarchy (events or “actions” hash) vs. participation in the inheritance hierarchy (event() or action() annotation). I would like to have the control to make that tradefoff, personally.