@name? name? self.name? def self.foo? def foo? What's the difference? And why does it seem like no one else is being confused by this stuff that doesn't seem to be explained well anywhere? ok def self.foo is a class method, like: class Account ... def self.authenticate(...) acct = Account.authenticate(...) def foo is just an instance method foo. Still scratching my head on the @foo/self.foo thing. ---- @foo is used inside a class definition to means "foo variable" self.foo means "calling foo method" of this object. The confusion may come from the fact that instance variable and getter method have the same name. Remeber that instance variable is always prefixed by '@'. all other than that is a method call. --------------------------------- It is both simpler and more subtle than it may at first appear. Much of the magic of rails (under the hood) is based on the interplay of these ideas. h3. def foo Add a method in the current scope. Inside a class definition, this adds an instance method to the class being defined--in other words, objects of this class will now have the method foo. h3. def anything.foo ... Add a method to anything. Anything can be an individual object, a class, whatever. If anything is a class (if, for example, you write def self.foo inside a class definition, the method will be a method of the class _not_ of instances of that class. h3. @foo An instance variable; only directtly accessible to methods of the object. h3. attr_accessor :foo A method call (equivelent to self.attr_accessor(:foo)). The method attr_accessor, called on a class, adds a pair of instance methods to the class, to get and set the value of an instance variable with the same name. It basically a short-cut way of writing: 
def foo
    @foo
    end
def foo=(new_val)
    @foo = new_val
    end
Note however that external users of the methods don't have any way of knowing is the value the get/set is simply being kept in an instance variable or processed in some other way. For instance, you could just as well something like write: 
def foo
    @foo || "default"
    end
def foo=(new_val)
    @foo = new_val unless new_value == "cheese"
    end
h3. Putting it together: From inside a method of an object, you have a choice: you can access the instance variables directly (via @foo) or you can use the same interface that outsiders would use (via self.foo). If you aren't writing your own getter/setter methods, the results are the same in either case. But if you _are_ writing getters and settters that do more than the defaults, it can matter a great deal and you should consider carefully which form matches your intensions. Note that it is possible for decendent classes to override the getter/setter methods (for example, to make them pickier about what values they'll accept). If you use self.foo you will get the advantages/limitations of the new behavior; if you use @foo you will be guarenteed that you are talking to the instance variable with no frills. ---- That really helped clear things up -- thanks! h3. Hash keys inconsistancy Another thing that's been bothering me: it seems like the usage of symbols and strings for hash keys is inconsistent. Why not just pick one and use it all the time? --------- The hash class allows for any sort of key (although with structured data that can change it is very easy to get yourself confused until you understand what's up)--you can use numbers, or colours or regualr expressions too. A large part of the strength of Hash comes from this generality, so wanting that to go away would indicate that you don't grok Hashes yet. So I'll assume your question is more along the lines of "why do particular people use one or the other in particular circumstances?" which is much harder to answer. You are of course free to pick one and use it all the time. But if you are using someone else's code, you need to be aware of what they expected--if you are lucky ( === they were thinking ahead) you can use either with impunity. But sometimes only strings (or only Symbols) will work--in much the same way that sometimes only an integer or only a real will do what you want. Do you have a specific instance in mind? ----- Yeah this was a Rails question more than a Ruby one, I suppose. I understand hashes and the usefulness of different types of keys (I know Python well). Here's an example http://ar.rubyonrails.com/classes/ActiveRecord/Base.html#M000287 "Also accepts keys as strings (for parsing from yaml for example)" And of course session hash keys are strings, and params, etc. For example, why 
link_to "foo", :controller => "blah"
and not 
link_to "foo", "controller" => "blah"
? I've even seen instances on the wiki where someone accidentally wrote @foo[:bar] instead of @foo["bar"] or vice versa. I suppose I just don't understand the use of symbols when strings are so ubiquitous. --------------------------- _laugh_ And I have a hard time using strings, since symbols are the way its always been done (we're talking over thirty years of habit here!). Apart from their long history: * Symbols are (at least in some circumstances) much faster * Symbols are atomic (the can't be edited, say, by gsub!) * Often what is needed internally is a symbol (methods, for example, are symbols, not strings) and so strings would have to be interned anyway I suspect the true answer, though, is a SongFromFidelerOnTheRoof. --[[MarkusQ]] Aha! Another thing that confused me about self.foo/@foo was the fact that inside of model methods, you can't just assign/read attributes by using @foo -- you have to use self.foo, or write_attribute/read_attribute. And that makes sense -- that way it can track what has does/doesn't need to be updated in the db on a save.