From: Dave Howell Date: 2006-01-06T23:40:36+09:00 Subject: Re: Demystifying Symbols. On Jan 5, 2006, at 12:54, Steve Litt wrote: > > I personally know of no use, in *my* application as opposed to Ruby > internals, > for the integer representation of a symbol. Exactly. So if I'm going to try explaining Symbols to somebody who's still trying to learn Ruby, I would completely omit any mention of the fact you could .to_i a Symbol. >> In fact, somebody correct me if I'm wrong, but I could actually never >> use a Symbol in a single line of Ruby code and I'd still be able to >> get >> everything done that I might reasonably want to. > > Except for giving up symbols' memory advantages and (probably slight) > performance advantages, that's my understanding also. I'm a newby; I'm not to the point that I care about memory advantages. I have a gigabyte to burn. Performance advantages appear to be nearly indetectable. Long before Symbols make a difference, I probably ought to learn many other far more relevant programming tricks to get more speed. > I don't think it would hurt to think of it as an immutable string (not > a > String), in your own personal life. However, that probably would not > go over > well on a mailing list :-) Yes, well, the fact that this mailing list was full of the most horrific dis-explanations of Symbols is one of the things that prompted me to *not* keep my thoughts to myself. > [clip] > >> A Symbol is a non-variable variable (aka a constant) that always and >> only contains its own name. > > That's an interesting and concise statement. I'll have to think about > that. Somebody else suggested thinking of them as "forevers," which is pretty cute. A variable is a box. You can put a sign on the box, like "current_user" or "amountPaid," and then put something in the box, put something else in, and on and on. (Yes, in Ruby one actually puts references in the box, not things. That is also a layer of complication inappropriate in an explanation to a newbie, although it can't be put off for long.) A constant is a wooden crate. You take something, build the crate around it, then stick the sign on the outside. Put a watermelon in a crate. Label it "oranges" if you like, but you can't put something else in once you've built it. A symbol is a crate with no label, but a clear cover. What you see is what you get; the label is also the contents. To restate the one-liner above: A Symbol is an unalterable (*) that always and only contains its own name. Damn. I can't find any word besides "variable" to go in that spot. "Container" is the functional description, and in programming, the first kind of container you meet (in every language I know) is called a variable, unless you learned Assembly first, and then it'd be "register." I can't support "literal," since as a programming term, I think it's quite obscure, which means I have to default to the general English meaning, and it's not remotely literal in that sense. Otherwise, I'd be able to sit down on a :chair. :) P. S. With duck-typing as a Virtue in Rubyville, when am I ever going to be presented with a method that won't accept a String as well as a Symbol? Would there ever be a reason besides "bad programming" to be that restrictive? P. P. S. The "contains itself" aspect of Symbols reminds me of Rexx. In Rexx, you can just use a variable without declaring it first, like Ruby. Unlike Ruby, a "new" Rexx variable doesn't contain "nil". It's initialized to its own name as a string. This would occasionally result in the most *peculiar* error messages.