Update: The belongs_to patch has now made it into core Rails. Thanks to Jon for persevering with it where I threw in the towel, and to Koz and Pratik for giving it their attention. I’m still not entirely convinced that going through the conventional channels (as opposed to “whinging on a blog”) would have yielded the crucial feedback to get the patch in a state where it could be accepted, but all’s well that ends well…
Take this as the rantings of a pissed-off curmudgeon who’s had his second core patch rejected if you will, but it’s my sad duty to report that Rails has jumped the shark. It happened when it stopped being a framework and started being a collection of opinions instead.
You see, in my book a framework is something that’s meant to make programmers work more effectively – not to lecture them about what they’re doing wrong. Lecturing can be a good thing, as long as it ultimately results in better code – I’ll happily admit that following the Rails learning curve has taught me an awful lot about good programming practices. More and more though, I’m finding it being used to justify just plain broken features: If it doesn’t work, it’s your fault for not doing it the right way. Take this bit of profoundly broken behaviour:
let’s say we have a Company model, which belongs_to :city
>> torchbox = Company.find_by_name('Torchbox')
=> #<Company id: 1, name: "Torchbox", city_id: 1>
>> torchbox.city
=> #<City id: 1, name: "London">
Aha, we’ve got the city wrong. Let’s reassign a bundle of attributes then, like we would if we were doing this through a web form:
>> torchbox.attributes = {:name => 'Torchbox', :city_id => 2}
=> {:name => 'Torchbox', :city_id => 2}
Right, so now we should retrieve the correct one.
>> torchbox.city => #<City id: 1, name: "London">
Er, oops.
(more…)