Primitive Base Class

[jimmydo]

This enhancement comes in two parts:

• The first commit adds a simple Backbone.Base class. This is a primitive base class you can use to create custom classes that can take advantage of the handy self-propagating extend() function, but do not need the functionality provided by any existing Backbone class (such as Model or View).
• The second commit is a little more invasive. It refactors the existing Backbone classes to inherit from Backbone.Base. It's pretty nice--at least for me--to have the constructor function of each class grouped along with the instance methods. I had to move ctor(), inherits(), extend(), and Backbone.Base further up the file so that they'd be available for use by the rest of the classes.

Feel free to take both, one, or none of the commits. :) I found the functionality useful, so I figured it'd be worth making a standard part of Backbone. Thanks for writing some really useful code.

[clutchski]

This would be great to see. We hack this by patching Backbone.extend into other types of classes in our app.

[PaulUithol]

Sounds useful to me as well. Right now (in backbone-relational ), I'm 'borrowing' extend from another Backbone class like so:

Backbone.Relation = function() {}; // constructor
// Fix inheritance :\
Backbone.Relation.extend = Backbone.Model.extend;

Would be nice to toss this.

[rxgx]

Is the philosophy of Backbone to provide an OOP implementation of JavaScript? In not, I would be cautious of using the term "class" and definitely not introduce more closures (inners) to provide class-like constructs that may impede the performance of prototypical inheritance.

[fbuchinger]

+1 for the separate Backbone.Base class.

[nowells]

+1. Would to great to expose this particularly useful internal for others to leverage as they see fit!

[farkashon]

+1. Why shouldn't Model/Collecton/View inherit from a base class that would be reusable elsewhere?
I'd love to see both commits inside the master.

[rc1]

+1. taking note of @rxgx's comment: could this be called Backbone.Object?

[tribalvibes]

+1 for this refactor @rxgx should however include a standardized way to call super

[rxgx]

@tribalvibes Instead of super, which is already being provided by goog.inherits, why not use Underscore's wrap method?

[tribalvibes]

@rxgx care to elaborate ? We're doing something like Klass.__super__.method.call(this,...) to call superclass methods, with just Backbone's version, not Closure. What are you suggesting we wrap?

[lukeholder]

+1

[tbranyen]

@jimmydo Mind updating this pull request, rebasing it and fixing merge conflicts? I'd really like to see this land, but I'd like a clean diff to compare.

[jimmydo]

@tbranyen Done.

@rc1 makes a good point. I can rename Backbone.Base to Backbone.Object. Any objections?

[tribalvibes]

Could also make the base be Backbone.Events as we remix this into app Model, View and Collection subclasses anyway.

[rc1]

I don't think the events functionality is needed in the Base/Object as it can be added to anything.

The advantage to having this Base:Object class is that the 'extend' pattern can be used on non-DOM related objects (canvas, rapheal) when backbone is available.

On 8 Nov 2011, at 19:13, [email protected] wrote:

Could also make the base be Backbone.Events as we remix this into app Model, View and Collection subclasses anyway.

---

Reply to this email directly or view it on GitHub:
#276 (comment)

[jimmydo]

Renamed Backbone.Base to Backbone.Object.

Yup, I agree with @rc1 that Backbone.Events should not be the base class.

[rc1]

Is this going to happen?

[rxgx]

I'm not sure it's possible since Backbone is built to emulate Java (with the help of Google) rather than embrace the prototypal nature of JavaScript (Object.create). If you're looking for an Abstract or Base class object like Namespace.Object, I'd look at Ember (Sprout Core 2) or Spine. Ultimately, the philosophy of how inheritance is implemented may be a point of frustration for you in the future.

[rc1]

I would not say the usefulness in this this proposal is to do with philosophy "of how inheritance is implemented" (please do correct me if I am wrong). The usefulness here is make a pattern accessible that Backbone.js uses. Is this a really interesting and useful pattern for many, and varied, different types of projects & uses?

[jashkenas]

Despite the popularity of this proposal -- I'm still reluctant to extend Backbone in the direction of providing a "class" library for JavaScript. Backbone is intended to deal with Models and Views and Events ... and the way that you desire to structure the rest of your app is up to you. If you'd like to take advantage of Backbone's extends, you can certainly do so yourself:

Backbone.Base = function(){};
Backbone.Base.extend = Backbone.Model.extend;

... done.

@rxgx: To put it politely, you're full of manure on this topic. Backbone's extend is 100% using prototypes in the way that prototypal inheritance works.

[maratbn]

Separating all logic into models, collections, views, and controllers / routers / etc is the right approach; however, there are times when, due to certain implementation details, it is not always possible to reuse the stock 'Model', 'Collection', 'View', or 'Router' that come with Backbone. In fact, even the 'Backbone.History' does not derive from any of these.

Adding this feature explicitly for local use is not super hard, even if it is a hassle for development and deployment, but the bigger issue here, is that resorting to a non-standard hack, which everybody does slightly differently, introduces more difficulties later on in exchanging Backbone-based code between applications developed by different authors / teams / organizations.

In addition, being absent from the public core of the Backbone environment also makes this feature be absent from the public core of the Backbone vocabulary shared across the Backbone community -- Since there is no such thing as the official "generic Backbone base class", it's not something that can just be quickly mentioned as part of larger discussion on StackOverflow or some other large forum without confusing anybody.

[braddunbar]

Hi @maratbn! While a base class implementation is certainly useful in some cases, I think @jashkenas is correct that exposing it won't improve Backbone. extend is used as the means to an end and exposing it as it's own end will only result in feature creep and complexity. Let's leave it as is, providing exactly what Backbone needs and no more.