Main Content

Scope of variables - important to Ruby on Rails

Archive - Originally posted on "The Horse's Mouth" - 2010-01-31 07:37:53 - Graham Ellis

Yesterday's Ruby on Rails training day brought home just how important it is to ensure that your Ruby variables are correctly "scoped" - that you tell Ruby if they're to be local to the method in which they are defined, to be available to all methods that run on the same objects, to all objects of a particular type, or throughout your entire program. You specify the different Ruby variable types by preceeding the variable name with appopriate characters - @, @@, $ or no special character at all.

stuff - a local variable
@stuff - an object variable (one per object)
@@stuff - a class variable (just one for a whole class of objects)
$stuff - a global variable (just one for the program)

There's a further writeup on our web site [here] including diagrams, and the full Ruby on Rails sample application where it was so important can be found [here]. I have also added an example which show each of the scope types to our directory of examples - it's [here].

Why is this scoping so important in Rails?

It's because Ruby on Rails uses ApplicationController classes (and subclasses thereof) to link in data from the model and pass it through to a view; variables that do not start with an @ or a $ aren't going to be visible to the viewer, whereas variables that do start with one of those characters will be.

Furthermore, if you have multiple application controller classes (as you're likely to do if you have a complex set of tables relating to different parts of a large application, looked after by a team of programmers), you need to be aware that common code / dynamic object variables are going to be best placed in the base ApplicationController class for sharing, whereas dynamic object variables that are specific to views of certain parts of the model only are best in the subclasses of the overall application controller.

In the example that's on our web site, where we are only managing two joined tables, we only have a single application controller subclass where we have chose to put all the logic - you can see that code [here]. The base class for common controller code is just an empty container that passed on the inheritance from the basic class that's supplied with the Ruby on Rails framework - you can see that (automatically generated, not altered by us in this case) file [here]