This post originated from an RSS feed registered with Ruby Buzz by Bryan Liles. Original Post: Subverting Rails Reserved Words Feed Title: Smarticus Feed URL: http://smartic.us/feed/atom.xml Feed Description: Ramblings of a ruby hacker Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Bryan Liles Latest Posts From Smarticus

I’ve been thinking about Rails reserved words lately, and I’ve come up with a solution that works in theory. Before I share my solution, let me help you understand where my frustration comes from.

ActiveRecord makes database access pretty darn simple. With two lines of code, you can be connected to a database and slurping data. A while back, I was making a template system, and unsurprisingly, I had a ActiveRecord class named Template, and a controller named TemplatesController.

As soon as I did this, I started running into errors:

What is happening here is that Rails is requiring an instance variable named @template, and I’ve stomped all over it by creating my own.

Here is another example of an error that had me boggled for way longer than it should have:

This happens be it looks like Rails is depending on another instance variable.

My solution for instance variables simple. In Views, Rails will set an instance variable with a not so common name. I’m leaning towards __variable_name__ or even __rails_instance_hash[:key]__. This way, there isn’t any confusion when it comes to instance variable names.

Another space where there are conflicts are in ActiveRecord models. You can’t have a text field called errors.

Rails assumes the errors method of your ActiveRecord object to be an instance of ActiveRecord::Errors.

In my opinion, this doesn’t make the most since. I believe we could apply the double underscores here as well. Instead of #errors, it would be #__errors__. You should be able to have any attribute name as long as it is legal for the underlying database. Rails should not be polluting your model namespace.

One problem with these changes is Rails has been like this for a few years now. Old code would break, so these types of changes would have to be introduced in a major release. The benefit of these changes could be huge. Lessening the chance that your code will tramp over Rails internals could be a great thing.