There is good explanation about symbol in the book. One thing that is still not clear to me is
that symbol sounds like a reference in languages like Java or pointers in C++. Can someone please
clarify if my understanding is correct? TIA
This is more of a Ruby-Talk question, but symbols are nothing like
pointers. They are more like constants, except their type is Symbol.
Some people like to think of them as immutable strings. Perhaps they
are more like C++ macros, if an analogy is possible. Pointers/
references refer to other objects that actually exist. Symbols really
*are* objects but their most commonly-used attribute is their name.
Hope this helps.
Not really: a symbol is simply a name. When we say :fred, we mean the name fred. When we say :has_many, we mean the name has_many.
They're a bit like read-only strings, but without any string methods. They're also very similar to integers: just like there's only one object that represents 42, there's only one symbol :forty_two. Whereever you type 42 in your program, you're referencing that one integer. Similarly, whereever you type :forty_two, you're referencing that same symbol. That's their power: you can use them as efficient ways of naming things, safe in the knowledge that a :duck is a :duck is a :duck.
Cheers
Dave
Hi --
There is good explanation about symbol in the book. One thing that
is still not clear to me is that symbol sounds like a reference in
languages like Java or pointers in C++. Can someone please clarify
if my understanding is correct? TIA
No, a symbol in Ruby isn't like a reference or pointer; a symbol does
not have any special relation to any other object.
I think one source of confusion with symbols is that the word
"symbol" can be used in two ways: to mean an instance of Symbol and,
more informally, as a general term for an identifier or token. So
here:
x = :hello
:hello is a Symbol object, but x is also a symbol, in the informal
sense. A Symbol object -- a symbol, in that sense -- does not point
to or represent anything other than itself.
See Dave Thomas's reply, especially concerning the similarity between
symbols and integers. I'd add that symbols are similar to integers
also in the sense that symbols, like integers, are used both by Ruby,
internally, and by us as programmers. But there's no connection
between Ruby's use and our use.
For example, consider this:
irb(main):020:0> s = "Hello"
=> "Hello"
# Ruby has entered the symbol :s into the local variable
# symbol table:
irb(main):021:0> Symbol.all_symbols.find {|s| s.to_s == "s" }
=> :s
# I can make use of :s myself:
irb(main):022:0> sym = :s
=> :s
I've got a variable called s, which means that Ruby creates a symbol
:s, internally. I can discover this via Symbol.all_symbols.
Now I assign the symbol :s to my variable sym. But this has nothing
to do with Ruby's use of the symbol :s. My two variables, sym and s,
have no connection to each other. Also, the fact that Ruby is using
:s to track something (local variables) has no connection to the fact
that I'm using the symbol :s in my program.
It's just like an integer -- say, 75. Ruby may have some reason to
store an internal count of 75 somethings; and I may have some reason
to use 75 in my program. But there's no connection between the two
uses.
David
Is it correct to say that Symbol represents a unique entity in the system? (unique label?)
Maybe I am beating the dead horse here. I have to read the replies several times to get this new
concept into my head.
Hi --
Same here, maybe someone has a good example of why :symbols are really useful?
-ryan
Firstly, there is the advantage of less memory consumption. Depending on what you do with the symbols, this may or may not be significant.
Secondly - and don’t discount this - symbols look nicer in a syntax-highlighting editor. This increases readability of code, which is significant.
There may be other reasons that I’m not aware of.
Cheers,
Max
Not really: a symbol is simply a name. When we say :fred, we mean the
name fred. When we say :has_many, we mean the name has_many.They're a bit like read-only strings, but without any string methods.
They're also very similar to integers: just like there's only one
object that represents 42, there's only one symbol :forty_two.
Whereever you type 42 in your program, you're referencing that one
integer. Similarly, whereever you type :forty_two, you're referencing
that same symbol. That's their power: you can use them as efficient
ways of naming things, safe in the knowledge that a :duck is a :duck
is a :duck.
When creating links in Rails, I see code that specify controller using symbols but the application
has multiple controllers. So :controller will be pointing to different controller for different
links. How does :controller remain constant in this case?
The symbol :controller is the key in a hash in this case, and the hash is a different instance for each link.
Best regards
Peter De Berdt
Hi --
Not really: a symbol is simply a name. When we say :fred, we mean the
name fred. When we say :has_many, we mean the name has_many.They're a bit like read-only strings, but without any string methods.
They're also very similar to integers: just like there's only one
object that represents 42, there's only one symbol :forty_two.
Whereever you type 42 in your program, you're referencing that one
integer. Similarly, whereever you type :forty_two, you're referencing
that same symbol. That's their power: you can use them as efficient
ways of naming things, safe in the knowledge that a :duck is a :duck
is a :duck.When creating links in Rails, I see code that specify controller
using symbols but the application has multiple controllers. So
:controller will be pointing to different controller for different
links. How does :controller remain constant in this case?
The same way the number 100 remains constant. Here's a hash:
{ 100 => "hi" }
and another:
{ 100 => "bye" }
I'm using 100 twice as a hash key. There's no connection between the
two hashes; the two uses of 100 don't "know" about each other.
Similarly, I can do this:
{ :x => "hi" }
and
{ :x => "bye" }
Here, I'm using the symbol :x twice as a hash key.
That's what Rails does with symbols like :controller. The symbol
:controller can serve any number of times as a hash key in different
hashes. The use of a hash key in one has does not bind the key to the
value, except in the context of that hash.
David
wannaknow wrote the following on 09.10.2006 19:03 :
"The use of a hash key in one has does not bind the key to the
value, except in the context of that has"..so why is this an advantage? why is this good? why go the extra mile
and learn about symbols? to gain...what?
1/ A string is a String object which is far more costlier than a Symbol
object.
You gain on memory usage and CPU time used for instanciation.
2/ A symbol doesn't look like a string -> it can convey a different
semantic content.
For example, I use symbols instead of strings everywhere there's an API
defined (everywhere I need to pass a hash of parameters, I use symbols
as keys, symbols can be used to represent possible object state values
too). Everywhere you don't need to treat a String object like a string
(printing it, calling concat, gsub, ...) you can probably assume that
using a symbol is more adequate (note that there's a place for constants
in there too, but it's a different subject). Having the IDE colorize
symbols differently from strings when you follow these conventions
presents cleaner code to the reader.
Lionel.
I did not notice that each hash has its own unique key and they are different hashes. Thanks for
the explanation. Now it is clear.
