Better name for .extend2 #1

Activity

1. machineghost commented on Mar 14, 2016

   

   machineghost

   on Mar 14, 2016

   Owner

   More actions

   The problem is, there is (potential) harm in over-riding the original.

   Let's say you write a Backbone library. You expect extend to behave as normal, so you do something like:

   var MyView = Backbone.View.extend({
       foo: ['bar'] // this should be replaced by sub-classes of MyView
   });
   

   Now someone uses your library, and makes a subclass of MyView. Because you told them to replace foo with their own value, they do this:

    var YourView = MyView.extend({
       foo: ['baz']
   });
   

   Everything works great! But then that someone decides they're also going to use BackSupport, which changes how extend works. Now suddenly the MyView code sees foo: ['bar', 'baz'] ... but it was expecting to get foo: ['baz'] so it causes a bug. And that bug isn't your (the library author's) fault, nor is it the user's fault: it's BackSupport's.

   So, to prevent that sort of scenario, I kept extend2 separate. However, as long as you're not worried about the issue I just described you absolutely can override Backbone.extend yourself. Something like the following should do the trick:

   Backbone.Model.prototype.extend = Backbone.View.prototype.extend = ... = BackSupport.View.prototype.extend2;
   
2. YSavir commented on Mar 19, 2016

   

   YSavir

   on Mar 19, 2016

   Author

   More actions

   Perhaps, but then I'd still go with a name such as .extend_with_support or something like that. If you don't want to override it, that's cool, but if so the function name should at least inform the reader of where it came from.

   👍React with 👍1Reacted by Emile J. Bergeron
3. machineghost commented on Mar 19, 2016

   

   machineghost

   on Mar 19, 2016

   Owner

   More actions

   I hear what you're saying, and I completely agree that methods should have informative names. However, I'm not sure extend_with_support effectively communicates the method's purpose either, and I also want to keep it as short and simple as possible.

   Names like extendWithOptionPreprocessing or extendWithMergedProperties are informative but long, while names like extendSmart or extendPlus (or extend2) fail to communicate the method's purpose ... perhaps extendMerge? It's still reasonably short, but it also conveys the key difference between extend and exendt2.
4. YSavir commented on Mar 25, 2016

   

   YSavir

   on Mar 25, 2016

   Author

   More actions

   extendMerge sounds great to me. Distinguishes what it does, doesn't override the default, and handy. I look forward to using it.

   👍React with 👍1Reacted by Emile J. Bergeron