Comments on: Evolving Rails: Retaining Backward Compatibility http://www.engineyard.com/blog/2009/evolving-rails-retaining-backward-compatibility/ Wed, 08 Feb 2012 12:12:12 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Evgeniy Dolzhenko http://www.engineyard.com/blog/2009/evolving-rails-retaining-backward-compatibility/comment-page-1/#comment-5492 Evgeniy Dolzhenko Wed, 15 Jul 2009 08:14:21 +0000 http://www.engineyard.com/blog/?p=1530#comment-5492 Hm, what's "when_fresh"? Hm, what's "when_fresh"?

]]> By: cies http://www.engineyard.com/blog/2009/evolving-rails-retaining-backward-compatibility/comment-page-1/#comment-5146 cies Tue, 14 Jul 2009 12:02:55 +0000 http://www.engineyard.com/blog/?p=1530#comment-5146 apis beautifully clean. there's art in it.. apis are what a framework/lib is about and in rubyland this is understood which makes rubyists happier people. but why the active*/action* thing? i understand it in case of ActiveRecord, it's like a brand and stems from the same named pattern. but for ActiveResource, ActionPack (ActiveController), ActiveSupport, ActionMailer and other cases, i dunno. just seems a little out of line with the uber-clean-api philosophy to me. like what you just proposed, can we not have a similar solution to this, like: class ActiveController < Rails::Controller; end and put that in the compatibility module (preferably with some deprecation warning) this way code will continue to work, yet we can name rails cleanly using its brand name: Rails. and packages like rails-support, rails-controller, rails-etc. a bit like merb. isn't this in the end a bit of an api-related beautification? apis beautifully clean. there's art in it.. apis are what a framework/lib is about and in rubyland this is understood which makes rubyists happier people.

but why the active*/action* thing? i understand it in case of ActiveRecord, it's like a brand and stems from the same named pattern. but for ActiveResource, ActionPack (ActiveController), ActiveSupport, ActionMailer and other cases, i dunno. just seems a little out of line with the uber-clean-api philosophy to me.

like what you just proposed, can we not have a similar solution to this, like:
class ActiveController < Rails::Controller; end
and put that in the compatibility module (preferably with some deprecation warning)

this way code will continue to work, yet we can name rails cleanly using its brand name: Rails. and packages like rails-support, rails-controller, rails-etc. a bit like merb.

isn't this in the end a bit of an api-related beautification?

]]>