Various code readability ideas #2059

wants to merge 24 commits into


None yet
7 participants

Hey Jeremy, here are some ideas left over from my code reading refactoring plus some new ones. I'd be happy to talk about these and tweak them as needed if you're interested in incorporating them.

Note that these changes, while aimed primarily at readability, do introduce some small incompatibilities/API changes. The main one is that I got rid of the 'unset' option in preference for treating attributes passed with a undefined value as unsetting those attributes. I think this is actually righteous since json can't represent an undefined value so a model with 'foo' present but undefined will serialize the same as a model with 'foo' simply not present. I had to comment out one test case which specifically tested that you could set an attribute to undefined.

Also I axed the changed property of Model. I assume that you've kept it around for backwards compatibility so you may still be unwilling to see it go. But it seems like a wart on the public API since you're not supposed to manipulate it directly.

Anyway, had fun playing around with this. Let me know what you think.


+ // The ChangeTracker is used by the Model to keep track of the state of
+ // changes made to the model's attributes so at to trigger

philfreo Jan 8, 2013


typo... "so as to"


jashkenas commented Jan 8, 2013

Thanks for writing this up as a pull request -- righteous and nicely OOP-y. I'll try to grab a chance to review it soon.


krawaller commented Jan 28, 2013

@gigamonkey I don't have anything constructive to add, just wanted to say - really cool refactoring! Nicely done! :)

Jeremy, any chance this is actually going to get folded in?


philfreo commented Mar 14, 2013

This refactor is pretty cool - @jashkenas thoughts?


jashkenas commented Mar 15, 2013

Whoops -- sorry, I had "[backbone]" tickets filtering out of the inbox for a couple of months there. It'll be time to come back around crank through some of these soon.


braddunbar commented Mar 15, 2013

I'm afraid this may not apply after the changes to Model#set. :(

Well, it's good to merge now and it's only been sitting around for 2 months. :-(


tbranyen commented Mar 15, 2013

@gigamonkey to be fair, it's typically better to bring up an issue first and then submit a pull request so theres no wasted efforts. jQuery encourages this so that people don't feel bad if ideas are turned down after they put significant time into a pull request.

Sure. I mentioned it to Jeremy before I started. And I'm cool with whatever you guys want to do. But if some other change was already in progress when I submitted my PR it would have been cool for someone to say, "Hey check this other upcoming change out and see if you can work with it." And if the other change came after mine, it'd have been nice if either mine had already been merged or if the other author had been told about my change.


tgriesser commented Mar 15, 2013

Sorry about that @gigamonkey - I think your request came in just after the decision was made to completely rewrite set and strip out queued changes entirely, and the pull request was more directed at/responded to by Jeremy, so I figured it'd be in his court to take a look through.


braddunbar commented Mar 18, 2013

I think @tgriesser's assessment is correct, but I'm sorry you spent time on this without being informed. We're attempting to address some of these organizational failings by using milestones to track features/fixes that are currently being worked on.


jashkenas commented Mar 19, 2013

I have to apologize for dropping the ball on this -- the fault is entirely mine for "commissioning" it at a poor time.

That said, I think there are a couple of issues with implementing this particular direction:

  • Ideally, we wouldn't introduce a new class that exists just to namespace some of the internal Model implementation. As the ChangeTracker is only ever instantiated within the Model constructor, it feels like it should simply be methods directly on the model itself.
  • That unset change is righteous -- you have a great point about the JSON, and we should definitely do that.
  • The model.changed property should stick around. It's useful, and is an intentionally-exposed part of the internals much like model.attributes is, or even Read-only reference properties.

So, closing, but thanks much!

@jashkenas jashkenas closed this Mar 19, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment