v2: Rename jQuery View hook methods

[jridgewell]

DO NOT MERGE, BREAKING CHANGE This is for the next major, v2.

To distinguish these methods from “private” methods (i.e. #_ensureElement).

[akre54]

Uh why? They're "private" here still. Other methods are exposed to plugins for overriding and they don't worry about naming either. The $ prefix looks ugly, imo.

[jridgewell]

They're hooks meant to be overridden, not private methods. Methods like #_ensureElement aren't meant to be overridden, and are subject to change in patch releases. Using the same naming convention for both doesn't seem like a smart idea.

---

I'm working on a PR that'll change #_ensureElement up a bit, which is what got me thinking of this.

[akre54]

But we've always exposed functions with the intention of allowing them to be overridden, either by plugin authors or end users. This is really no different than allowing an associations plugin to override get and set and expecting that to work. We shouldn't handle View's hooks any different than anywhere else in the code.

[jridgewell]

But we've always exposed functions with the intention of allowing them to be overridden, either by plugin authors or end users.

I don't see methods like Model#_validate and Collection#_removeModels, Collection#_onModelEvent, etc as publicly supported hook methods. That they're accessible on the prototype is due to code organization, not that they're meant for an end user to override. I'd argue that our private methods shouldn't be overridden ever: we're not obligated to keep them around between versions.

This is really no different than allowing an associations plugin to override get and set and expecting that to work.

#get and #set are both public methods with defined functionality. Changing them requires a new major.

We shouldn't handle View's hooks any different than anywhere else in the code.

I'm working on exposing our other hooks (Collection#_isModel springs to mind) publicly. But our internal methods shouldn't look like hook methods.

[braddunbar]

They're hooks meant to be overridden, not private methods.

Underscored methods are certainly meant to be overridden. Otherwise, we'd hide them in local scope, no? The distinction is that they're less stable and could be changed without the same notice as public API. My opinion would be that these methods fit that description.

[megawac]

👎 this seems like an unnecessary reason to break code and overall poor change