4 ms·
The nice thing about negative posts like this — or, somewhat negative, in this case — is that they validate the bottled up frustrations of developers who though
by mapgrep 15y ago
The nice thing about negative posts like this — or, somewhat negative, in this case — is that they validate the bottled up frustrations of developers who thought the same thing.
For example, I always wondered if I was crazy to be frustrated that Rails gratuitously changed the method for grabbing all records from .find_all to .find(:all) to .all. In other words, they went from having a full method to having a param to a broader method and then BACK to having a full method. And along the way they disabled the old methods, without even providing stubs (e.g. a find_all that called find(:all), until at least one full version had passed).
There also seemed to be flip flopping on Rails engines. Engine support was built in to early versions of Rails, and an actively community sprung up. Then at one point DHH was actively discouraging them, saying they were a mistake, to the point where the author of one engine I relied on (login engine) just abandoned it and stopped updating it for new versions of Rails so I had to write a bunch of login code to migrate to some version of Rails (2 maybe?). ("This is a sideshow project" --DHH http://weblog.rubyonrails.org/2005/11/11/why-engines-and-components-are-not-evil-but-distracting http://weblog.rubyonrails.org/2005/11/11/why-engines-and-com... ) Now engines seem to be back again - the documentation states "Since Rails 3.0, every Rails::Application is just an engine" http://edgeapi.rubyonrails.org/classes/Rails/Engine.html http://edgeapi.rubyonrails.org/classes/Rails/Engine.html So engines went from a "distracting... sideshow" to the core of rails apps. Hmm.
It's somewhat validating to read I'm not the only one frustrated at the common and sometimes publicly reverted changes in rails.
- petercooper 15y agoIn other words, they went from having a full method to having a param to a broader method and then BACK to having a full method. You may know this but I wanted to note that this was not a "revert" as such in case less informed third parties thought this was capricious API design at its worst. Today's #all is rather different to yesterday's #find_all in that the former supports chaining and is lazy evaluated, whereas the latter used to immediately hit the DB and required criteria to be included all in the one call.
- mapgrep 15y agoInteresting. Do you know (honest question) why they didn't just make find(:all) work that way? In my imagined perfect world they'd have never got rid of find_all in the first place, and they'd have just added the lazy eval to it later. Or, failing that, done similar with find(:all). Enjoy your podcast.
- petercooper 15y agoAs I'm not on the Rails core team and didn't really pay much attention to their design process, all I can offer is the major rewrite of ActiveRecord from 2 to 3 and, specifically, the introduction of Arel in AR3 had huge implications for the API design. Specifically, check out the README at https://github.com/rails/arel https://github.com/rails/arel .. if you're familiar with Rails 2 and earlier, the sorts of things you'll see there probably seem quite alien to you. I believe AR had to change a lot to fit in with this approach to SQL generation. (And thanks!)
- samgranieri 15y agoIIRC "engines" were never built into rails (before 3.0). I believe you were referring to this plugin: https://github.com/lazyatom/engines https://github.com/lazyatom/engines. Honestly, before rails 3, the whole plugin initialization process was a mess. Things are a lot better now. Props to yehuda katz for great work on refactoring on rails 3. What's wrong with cutting backwards compatibility with old apis after a while? The core team does provide deprecation warnings when they plan on changing stuff, so it's not a complete surprise.