rails pollution

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.

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.

...

So... Who wants to do the rewrite?

:wink:

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

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.

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.

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.