Instance variables in Ruby and Rails

[elz]

I was trying to explain this to someone earlier while doing a couple other things and was making a muddle of it. So here's a somewhat-more-coherent explanation:

Ruby

If the terms 'class' and 'instance' are still unfamiliar to you, think of it this way:

class : instance
Superhero : batman
Vulcan : spock
Planet : earth
Website : dreamwidth

A class is a general type of thing, an instance is one of those things. So it follows pretty logically that a class variable stores information about the whole class and an instance variable stores information about an instance of that class. @@this is a class variable and @this is an instance variable.

Let's say my Superhero class looks like this:

class Superhero
  def secret_identity=(name)
    @secret_identity = name  
  end
	
  def secret_identity
    @secret_identity
  end
end

I can then create a new superhero like this:

batman = Superhero.new
batman.secret_identity = "Bruce Wayne"

And then when I type in batman.secret_identity again, it should say "Bruce Wayne". If I then do:

superman = Superhero.new
superman.secret_identity = "Clark Kent"

batman.secret_identity is still "Bruce Wayne", and superman.secret_identity is "Clark Kent".

So what you'll notice is:

1. Each instance can have its own @secret_identity, and they don't conflict with one another.


2. The value of @secret_identity sticks around and can be accessed and changed by any of the instance methods in the class. (You don't want to use instance variables in class methods, though. Badness will ensue.)


3. I did have to create methods to let you access the instance variable from outside the class - you can't get to it directly.


4. @secret_identity happens to be a string, but you could have an instance variable called @nemeses that stored an array of supervillains. Like all Ruby variables, instance variables can contain anything.

(NB: in practice, of course, always take steps to keep your secret identity from being read by the wrong people.)

Class variables are a bit less common, but you can imagine that the Vulcan class has something like this: @@shape_of_ears = "pointy". Doesn't really matter if you're talking about Spock or T'Pol: each Vulcan has pointy ears, and all Vulcans have pointy ears. The danger is that if you change @@shape_of_ears anywhere, it's changed everywhere. And you don't want to mess with Spock's ears.

Rails

So now we come to Rails, and if you've used Rails a bit already, you may be more rather than less confused, because instance variables are usually used in controllers and views, and they're specifically used to send information from the controller to the view. I put a bunch of people in @people in my controller action, and I can get those same people out of @people in my view file. What happened to not being able to access instance variables from outside the class they belong to?

This is actually Rails pulling a fast one on you. You're not accessing the controller's instance variables; what happens is that when a view is rendered, Rails takes all the instance variables in the controller action, clones them, and hands the clones off to the view. That's why you can get to the values of those variables when you render a view (either by default or by using 'render'), but not when you redirect - redirect_to sends you to a different controller action which renders its own view, giving you a whole different army of clones. So to speak.



Let me know if you have any questions, additions or corrections!

Comments

KVwdsCZyDPJUebpH

[(Anonymous)]

The core ethical value dettrsmnaoed in Seedfolks is responsibility because all the characters are responsible for taking care of their garden. Another core ethical value shown is respect because since all the characters are meeting one another throughout the process of creating this garden, they are also getting to know each other, and it takes respect to do that.

mXMqEcNzKtdRSFRqH

[(Anonymous)]

The end goal for BrowserID involves naitve browser support for authentication, using public-key crypto with the keys generated and stored by the browser. browserid.org exists as a compatibility shim to make BrowserID universally available *before* browsers have naitve support for it; they really need to document that plan better on the site.(Also, you could implement BrowserID server-side without JavaScript; browserid.org implements it client-side using JavaScript to avoid the need for specialized server-side code on each site adopting it, which greatly simplifies adoption.)OpenID requires a webpage supporting a specialized authentication protocol which websites don't normally implement. You can't use OpenID with an arbitrary homepage URL without either hosting an OpenID implementation yourself or delegating to a third-party authentication provider. More importantly, having a personal OpenID that doesn't depend on a third-party account requires hosting a personal homepage, which not every Internet user has or needs. As a result, in practice, the vast majority of OpenID users rely on a third-party identity provider such as the dozen whose icons you show at the top of this form, and that seems unlikely to ever change.BrowserID specifically ties identity to an email address, which everyone with Internet access already has. People can easily obtain an email address in their own name and at their own domain, and use that as their BrowserID, *without* having to seek out additional support for a specialized protocol as in OpenID. Also, almost all sites already want an email address when signing up, so using BrowserID avoids the need to deal with other pieces of information. BrowserID supports changing that email address, so that you don't get stuck with a pile of accounts using when you've migrated to . BrowserID also pre-validates the email address, which means you don't have to redo the usual email-a-link verification with every single site.You mentioned that you have three email addresses and only one homepage. That case actually works *better* with BrowserID, which offers you the choice of which email address you want to use to authenticate to any given site. So, you can easily maintain accounts for , , or , without needing to host three homepages or rely on third-party authentication providers.As for using multiple browsers, BrowserID supports migrating from browserid.org to in-browser authentication without changing anything visible to sites, and browsers which support in-browser authentication will almost certainly support migrating or sharing identities between themselves.So, I personally prefer BrowserID because it gives me more control over my own identity, lets me maintain multiple identities as easily as having multiple email addresses, avoids tying my account with a site to an account I currently have with a third party (and may want to drop in the future), reduces the number of pieces of information I need to provide to sites to one, eliminates the per-site email verification, and provides a path leading to in-browser crypto-based authentication.Does that help answer your question?

QOwpSgNFzHORGZcuq

[(Anonymous)]

Hi Gabriel,I have incorporated CustomItemGenerator' into my prjecots and now I want to work with automated unit testing using NUnit Framework on one of my project.When I access the properties (like CustomTextField) generated through CustomItemGenerator' in NUnit GUI it throws error, below is the stack trace of error -at Sitecore.Pipelines.RenderField.RenderFieldArgs..ctor()at Sitecore.Web.UI.WebControls.FieldRenderer.RenderField()at Sitecore.Web.UI.WebControls.FieldRenderer.Render()at CustomItemGenerator.Fields.BaseCustomField`1.get_Rendered()at CustomItemGenerator.Fields.SimpleTypes.CustomTextField.get_Text()But when I create my own properties (string type) in the same class (generated through CustomItemGenerator'), they are accessible in NUnit GUI.It would be great if you can provide some help on this problem.