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.