Should this be: return this.attributes[attr] !== null;

Nope. !== null just matches null in JavaScript. != null matches both null and undefined.

Ah, ok. Thank you for the clarification.

Please, consider ":entity?*args"

c._routeToRegExp('query?*args') compiles to /^query?(.*?)$/ and does match "queradsdasd" which is wrong

Revised the test here:

c0c8cb2

Still passes.

And no, it doesn't compile that way -- the question mark is escaped with a slash.

Right, my fault. Didn't pulled the git... Thanks!

Always wondered whether it's feasible to support the single node-style callback (function(err, result){...}) in options instead of .error/.success?

(Talking as a huge node fan:) I don't think this is a good idea. This is mainly a browser-side mvc framework and it is common syntax in the browser-js world to use error/success options. Changing it to the node style just adds another barrier for beginners (although a small one) and adds very little.

Frankly, Events/Model/Collection and even Controller code seems very easy to adopt to server-side. Backbone.sync should leverage the real DB calls, Views can be noop. Callbacks due to DB asynchronity are easily wrapped so they'd use success/error.

The only what stops me is that models have truly reference to the their collection (instead of just caching collection.remove and collection.url()) and thus undesirable snoop can be from one model to siblings.

In my fork I coped with that, although jashkenas stated it's not feasible

I'm afraid that I'm of the same opinion as maritz -- the {success: ..., error: ...} API is the one we want to use.

or more simply:
return Boolean(this.attributes[attr]);

This should be :
if (attr == this.idAttribute) delete this[attr];
I think...

Nope ... we're maintaining the "id" property as the public API -- it just gets its data from the source you specify.

Yes, right, sorry :)

This test will never equal true as the hash value set does not equal the test string. There is an 'a' at the end of the string.

The typo was fixed in the following commit: 164ad72#diff-3

I fear if one included jQuery and not included underscore, we'll be wrongly getting _ = jQuery here.

And then things will break, in exactly the same way they would have before this change.

I see. Just thought we'd want to fallback to requiring underscore in this case

This ends up calling the model's initialize function without access to any of it's data. This means that you can't add a plain Object into Collection#add and expect it to initialize the same way.

var o = { prop: 'yarr' };
var SomeModel = Backbone.Model.extend({
  initialize: function(){
    var prop = this.get('prop');
    console.log(prop); // prop will be undefined if the model is created via Collection#add, but will exist if created using new SomeModel(o)
  }
});

Yeah - I agree this is not ideal. This is the behavior Collection.create has had all along though; but maybe it's better to take the behavior from Collection._add.

Is there are reason why we are creating the model in two steps #564 and #565 ? Why can't we just do it the old way new this.model(attrs, {collection: this}); ?

Well, yes; there were bugs filed against that method (previously used in Collection._add), and not against this one (previously used in Collection.create). The issue is that Model.constructor calls set(attrs, {silent: true}), which doesn't pass options to set, and thus disables validation. It's possible of course, but then we should find some way to have validation as well for those that need/want it; maybe Model.constructor could get a slight tweak to something like this?

options || (options = {});
this.set(attributes, _.defaults(options, {silent : true}));

I don't know what should happen if this.set returns false though (validation fails)...

Are the capture groups necessary here? It should speed things up (trivially) by removing those; the [\w\d]+ character class should work just fine by itself. AFAIK, these regexs are only used with String.replace - which isn't making use of the captured groups.