rails pollution

rubyonrails-core
1

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.

A while back, I was making a template system, and unsurprisingly, I had a ActiveRecord class named Template, and a controller named TemplatesController. Rails is using an instance variable named @template, and I’ve stomped all over it by creating my own. The same thing happened when I had a resource called Url.

http://idisk.mac.com/osesm/Public/Pictures/Skitch/Action_Controller__Exception_caught-20080702-064151.png http://idisk.mac.com/osesm/Public/Pictures/Skitch/Action_Controller__Exception_caught-20080702-064419.png

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.

http://idisk.mac.com/osesm/Public/Pictures/Skitch/bryan%40dmac__tmp_template_test-20080702-065201.png http://idisk.mac.com/osesm/Public/Pictures/Skitch/bryan%40dmac__tmp_template_test-20080702-065302.png

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 sense. 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.

2

I heartily support your observations: losing so many names to "reserved" status is so incongruous in this so-called modern age of technology! For those of us who enjoyed the world of FORTRAN, a construct which had no reserved words, losing such common nouns as "type", "error", "group", etc (especially when context should net exclude their use) is anachronistic.

3

...

So... Who wants to do the rewrite?

:wink:

4

Whilst the point is entirely valid, IMHO there is equally a sense of 'polluting' the code with loads of __ stuff. The thing I really like about ruby and rails is the nice readability factor.

I have been bitten by errors, and template name clashes and the like, but coming up with an extended name in the app is usually fairly trivial.

After all, you are going to inflict __ throughout every application in every situation. That would be a shame since I would have thought that in many cases problems with name conflicts occur rarely.

Tonypm

5

I have been bitten by errors, and template name clashes and the like, but coming up with an extended name in the app is usually fairly trivial.

This is where I take issue. Coding around the framework feels weird.

After all, you are going to inflict __ throughout every application in every situation. That would be a shame since I would have thought that in many cases problems with name conflicts occur rarely.

You won't see the __ as much as you think. The __ is for framework defined instance variables (in the templates). I also put up an example about #errors in ActiveRecord::Base. In this case, I wouldn't mind dipping into another namespace to get my errors, but I'm not convinced my solution is optimal.

6

I think it'd be pretty annoying to start using #validation_errors. There are a bunch of other public methods that could potentially run into issues. It's probably easy enough to just create a custom accessor:

def foo_errors   self[:errors] end

def foo_errors=(value)   self[:errors] = value end

I agree that the internal variables should have ugly underscored names. The problem is that it's not exactly trivial to replace everything in a way that doesn't trash someone else's existing app or plugin. I'd suggest starting a git branch started and having folks run it against their apps to see what breaks.

7

I agree that the internal variables should have ugly underscored names. The problem is that it's not exactly trivial to replace everything in a way that doesn't trash someone else's existing app or plugin. I'd suggest starting a git branch started and having folks run it against their apps to see what breaks.

I certainly think it's worth experimenting with this, however you'll need to set yourself a reasonable scope. A git branch which renames every single instance variable is unlikely to be useful. Perhaps start with things like @template in actionpack and the association proxy's instance variables. I think a single underscore prefix will do, that's what we do already with @_request and friends.