I think it's because A LOT of us were wondering the same thing. In general,
RUBY conforms beautifully to Eric Raymond's "Rule of Least Surprise". IMHO
symbols are an exception.
Tell you the truth, I still don't understand, but at least now I have some
theorys thanks to the thread you started. Thank you for that.
SteveT
Steve Litt
slitt@troubleshooters.com
On Thursday 29 December 2005 03:03 am, Surgeon wrote:
Oh, so many replies to my poor question! What a wonderful community!
I plead ignorance on Perl barewords. I use "use strict" every time.
SteveT
Steve Litt
slitt@troubleshooters.com
On Friday 30 December 2005 10:55 am, Austin Ziegler wrote:
It's not that different from Perl
barewords.
My understanding is that barewords are not persistent atomic elements of
code the way symbols are -- they are immediately slotted into some other
syntactic meaning by context, and if context doesn't suggest any meaning
in particular, they're assumed to be strings. In general, what this
means is that if you use a word without hints to what it is, it's a
subroutine if you have defined a subroutine by that name, and otherwise
it's just a shorthand way of using a literal string by omitting quotes.
To compare a symbol to that seems to be short-changing the potential
uses of symbols.
There is a Symbol module for Perl, which I haven't used and
unfortunately don't know much about, but my understanding is that it's
pretty limited in comparison with Lisp (or, now, Ruby) symbols, in that
it's just a wrapper for globs. It seems to me that if you want to draw
a comparison between Ruby symbols and something in Perl, globs are the
better choice, in fact, as far as the way they "act" under pressure,
though they are limited in that where a Ruby symbol is "a name" for
anything, a Perl glob is "a name" only within a filehandle context.
I haven't really thought about it before this, but I'm actually kinda
disappointed that Perl doesn't have a fully operational death star . . .
err, I mean that it doesn't have anything like symbols, except in a very
limited sense.
On Sat, Dec 31, 2005 at 12:55:55AM +0900, Austin Ziegler wrote:
Hopefully that's a bit clearer. It's not that different from Perl
barewords.
--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
I'm somewhat new to ruby, and for me it has made most sense to do an ri
on Symbol to check out the api. When I first ran across symbols in the
Pickaxe it didn't make much sense. I started out just taking it on
blind faith how they get used in different frameworks api's. Seems
like what symbols are is different from how they might be best used.
Here's something I wrote up to play around with how they work. I was
surprized to find out that any identifier (class, method, variable,
etc) in a ruby script gets turned into a symbol.Bill
# Definition: A symbol is an object of class Symbol. The symbol
# has only one instance with given name that can be found by
# calling the method id2name or to_s. The symbol has a unique
# integer value that can be found by calling the to_i method.
# The Symbol class method all_symbols will give an array of all
# symbols. A symbol is automatically generated for any
# identifier used or seen within a ruby program including
# constants, classes, methods, variables, etc. Once a symbol is
# created it is never garbage collected.
S'funny, my RI says:
+Symbol+ objects represent names and some strings inside the Ruby
interpreter. They are generated using the +:name+ and +:"string"+
literals syntax, and by the various +to_sym+ methods. The same
+Symbol+ object will be created for a given name or string for the
duration of a program's execution, regardless of the context or
meaning of that name. Thus if +Fred+ is a constant in one context,
a method in another, and a class in a third, the +Symbol+ +:Fred+
will be the same object in all three contexts.
But anyway,
def find_and_display_symbol(symbol_name)
found_symbol = Symbol.all_symbols.find { |s| s.to_s == symbol_name }
if (found_symbol != nil)
puts "symbol found with name: #{found_symbol.to_s} and " +
"id: #{found_symbol.to_i}\n\n"
else
puts "unable to find symbol #{symbol_name}\n\n"
end
end# create a symbol object called symbol_name
:my_new_symbol# display the newly created symbol by going through all symbols
# see find_and_display_symbol function below
find_and_display_symbol('my_new_symbol')# symbols apparently don't have to be a legal identifier
:"Hello World!"
find_and_display_symbol("Hello World!")#local variable creates a symbol
silly_local_variable = "Hello"
find_and_display_symbol('silly_local_variable')# Any referenced identifier will create a symbol, even if the symbol is
# undefined:
defined? undefined_variable
find_and_display_symbol('undefined_variable')# Symbols already exist for builtin classes and methods
find_and_display_symbol('String')
find_and_display_symbol('each')
find_and_display_symbol('$LOAD_PATH')# list all symbols
sym_array = Symbol.all_symbols
sym_array.sort! {|a,b| a.to_s <=> b.to_s }
sym_array.each {|s| puts "name: #{s.to_s} id: #{s.to_i}\n" }
Hey, that could be a good basis for a nuby file for my collection (http://roscopeco.co.uk/code/noob\), maybe as part of an expanded version of the existing syms-methods thing (which isn't too hot anyway to be honest). Mind me doing that?
Cheers,
On Sat, 31 Dec 2005 20:10:13 -0000, <Bill.Dolinar@gmail.com> wrote:
--
Ross Bamford - rosco@roscopeco.remove.co.uk
Hi --
Oh, so many replies to my poor question! What a wonderful community!
I think it's because A LOT of us were wondering the same thing. In general,
RUBY conforms beautifully to Eric Raymond's "Rule of Least Surprise". IMHO
s/RUBY/Ruby/ 
In Ruby, P[olicy]OLS refers to what does or does not
surprise Matz.
symbols are an exception.
A little surprise is OK. As Yohanes says, it's part of the learning
curve -- and Ruby does have a learning curve, even though it's
relatively gentle. The language has to be "allowed" to do things in a
way that are not identical to what programmers of other languages
expect. Otherwise its existence would serve no purpose.
Just out of curiosity: can you describe how symbols would work if
they weren't surprising?
David
On Thu, 29 Dec 2005, Steve Litt wrote:
On Thursday 29 December 2005 03:03 am, Surgeon wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
Not at all. Use whatever parts you would like.
Bill
They wouldn't exist, or they wouldn't be called symbols. If I'm referring to
an instance instead of a value, I could call it &variable as in C, or I could
call it :variable, but in that case I'd call it a reference, not a symbol.
Personally, I think of the referencing and dereferencing in C as being
unsurprising. C has plenty of surprises, but referencing and dereferencing is
not one.
From what I understand, symbols are used for things other than naming
objects/variables. In such cases, it would be less surprising if they had a
different syntax than the ones that name objects.
A little surprise is OK. The subtle differnces of do/end and {/} in blocks is
a little surprise. But in my opinion, symbols and their uses is a blizzard on
the equator type surprise.
The fact that symbols cause so much more confusion than most other Ruby
facilities is an indicator. AFAIK there has been no good documentation on
symbols. When I mean good, I mean like the thoughts that have gone into this
thread -- thoughts valuable to the person who doesn't yet know symbols by
instinct, at which time the documentation is moot anyway.
SteveT
Steve Litt
slitt@troubleshooters.com
On Thursday 29 December 2005 10:16 am, dblack@wobblini.net wrote:
Hi --
On Thu, 29 Dec 2005, Steve Litt wrote:
> On Thursday 29 December 2005 03:03 am, Surgeon wrote:
>> Oh, so many replies to my poor question! What a wonderful community!
>
> I think it's because A LOT of us were wondering the same thing. In
> general, RUBY conforms beautifully to Eric Raymond's "Rule of Least
> Surprise". IMHOs/RUBY/Ruby/
surprise Matz.> symbols are an exception.
A little surprise is OK. As Yohanes says, it's part of the learning
curve -- and Ruby does have a learning curve, even though it's
relatively gentle. The language has to be "allowed" to do things in a
way that are not identical to what programmers of other languages
expect. Otherwise its existence would serve no purpose.Just out of curiosity: can you describe how symbols would work if
they weren't surprising?
Hi --
Just out of curiosity: can you describe how symbols would work if
they weren't surprising?They wouldn't exist, or they wouldn't be called symbols. If I'm referring to
an instance instead of a value, I could call it &variable as in C, or I could
call it :variable, but in that case I'd call it a reference, not a symbol.
But it's not a reference; it's an object, of class Symbol. If you do:
s = :sym
then the variable s holds a reference to the object :sym, just as when
you do:
a =
a holds a reference to that array.
Personally, I think of the referencing and dereferencing in C as being
unsurprising. C has plenty of surprises, but referencing and dereferencing is
not one.
Referencing and related things are so completely different as between
Ruby and C, though. They really don't map onto each other at all.
From what I understand, symbols are used for things other than naming
objects/variables. In such cases, it would be less surprising if they had a
different syntax than the ones that name objects.
They do; they have a literal constructor (:sym). That's always a
symbol first and foremost; and if there happens to be a method called
"sym", there may be some contexts in which you can use a symbol to
refer to it, but that's only because something is implemented to do
that (such as: obj.method(:sym)).
I think one important key to understanding symbol objects is their
immediacy. When you see :sym, it's very similar to seeing an integer.
It *is* the object. What gets done with the object, or what methods
do or do not know how to use it to pry out methods or other things, is
secondary.
David
On Fri, 30 Dec 2005, Steve Litt wrote:
On Thursday 29 December 2005 10:16 am, dblack@wobblini.net wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
You are still confused. <laughs>
Symbols are nothing like references. They would be much closer to enums, if you want a C-ish comparison.
James Edward Gray II
On Dec 29, 2005, at 9:45 AM, Steve Litt wrote:
On Thursday 29 December 2005 10:16 am, dblack@wobblini.net wrote:
Just out of curiosity: can you describe how symbols would work if
they weren't surprising?They wouldn't exist, or they wouldn't be called symbols. If I'm referring to
an instance instead of a value, I could call it &variable as in C, or I could
call it :variable, but in that case I'd call it a reference, not a symbol.
It's not a reference. Symbols are much simpler than that. Really. They are
just an integer with some sequence of characters to represent it, all wrapped
up in an object.
:foo has nothing to do with a variable named @foo, or a method named foo() or
anything else. It's just the characters "foo" associated with an integer.
That association lasts for the life of the Ruby interpreter process.
That's all there is to it. They are _simple_ constructs. My hunch is that
the confusion for people new to the language is simply that they are trying
to map them to something more complex than Symbols really are, and they don't
happen to find any clear, concise, handy documentation to explain them.
Kirk Haines
On Thursday 29 December 2005 8:45 am, Steve Litt wrote:
They wouldn't exist, or they wouldn't be called symbols. If I'm referring
to an instance instead of a value, I could call it &variable as in C, or I
could call it :variable, but in that case I'd call it a reference, not a
symbol.
They wouldn't exist, or they wouldn't be called symbols. If I'm referring to
an instance instead of a value, I could call it &variable as in C, or I could
call it :variable, but in that case I'd call it a reference, not a symbol.
When I do the following:
attr_accessor :foo
I am not referencing anything. I am naming something. There is no
analogue between a Ruby Symbol and a C/C++ reference or pointer.
Symbols name things, and they are important enough that they are
intrinsic types just like Strings, Arrays, Hashes, and Integers. What
makes Symbols "special" in the current implementation is that a Symbol
is created for every named item.
>> olds = Symbol.all_symbols; nil
nil
>> quuxl = 0
0
>> Symbol.all_symbols - olds
[:quuxl]
But as I stated in the blog entry I posted above, the Symbol is just a
name. What gives a Symbol its power is the thing that uses it, such as
attr_accessor. Symbols are names. No more, no less.
Really, I think that people create the confusion for themselves,
expecting them to be more than they are.
-austin
On 29/12/05, Steve Litt <slitt@earthlink.net> wrote:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
OK, let me see if I'm correctly understanding you.
:wilbur is an object. That object has two properties, which one could call, in
generic and not Ruby terms, a key and a value. The key is an integer. The
value is "wilbur". Neither the key nor the value can be changed during the
execution of the program. When we write:
attr_accessor :wilbur
what really happens is that the function attr_accessor() takes symbol :wilbur
as an argument, tacks on a @ to the string's value in order to make the true
class variable @wilbur, and then writes a tiny get and set functions whose
names are wilbur, such that:
my_object.wilbur = 22
puts my_object.wilbur
So my initial comment that it seemed like magic is true only to the extent
that the "magic" performed by attr_accessor is to create the set and get
methods with the same name as the symbol that is its argument.
Do I understand what you're saying?
Thanks
SteveT
Steve Litt
slitt@troubleshooters.com
On Thursday 29 December 2005 11:20 am, Kirk Haines wrote:
On Thursday 29 December 2005 8:45 am, Steve Litt wrote:
> They wouldn't exist, or they wouldn't be called symbols. If I'm referring
> to an instance instead of a value, I could call it &variable as in C, or
> I could call it :variable, but in that case I'd call it a reference, not
> a symbol.It's not a reference. Symbols are much simpler than that. Really. They
are just an integer with some sequence of characters to represent it, all
wrapped up in an object.
Thanks Austin,
I *think* that article brought me closer to understanding. Armed with your
article and all the other responses, I replied to Kirk Haines' post with my
interpretation of what you all were saying.
By the way, your article is obviously needed, and you should probably refine
it as time goes on. The fact that we had so many responses that at least in
part contradicted each other indicates to me that symbols are perhaps the
most surprising element of Ruby, which is otherwise not a surprising language
at all.
Thanks for the great blog entry.
SteveT
Steve Litt
slitt@troubleshooters.com
On Thursday 29 December 2005 11:30 am, Austin Ziegler wrote:
On 29/12/05, Steve Litt <slitt@earthlink.net> wrote:
> They wouldn't exist, or they wouldn't be called symbols. If I'm referring
> to an instance instead of a value, I could call it &variable as in C, or
> I could call it :variable, but in that case I'd call it a reference, not
> a symbol.http://www.oreillynet.com/ruby/blog/2005/12/symbols_strings_methods_and_va\.
html
<snip>
What
makes Symbols "special" in the current implementation is that a Symbol
is created for every named item.>> olds = Symbol.all_symbols; nil
nil
>> quuxl = 0
0
>> Symbol.all_symbols - olds
[:quuxl]But as I stated in the blog entry I posted above, the Symbol is just a
name. What gives a Symbol its power is the thing that uses it, such as
attr_accessor. Symbols are names. No more, no less.Really, I think that people create the confusion for themselves,
expecting them to be more than they are.-austin
I think that the same thing that "makes symbols 'special' in the
current implementation" is what creates confusion for people.
I know that the idea that the "thingy" in the symbol table is the same
"thingy" represented by an immediate object that has a literal
representation seemed very voodoo/black magic to me at first, coming
from languages where the symbol table is a hidden, reserved, internal
sort of structure. From the outside, Symbols look like they were
invented solely to facilitate meta-programming, which is why they have
all the "name" conceptual baggage attached.
In other words, to a non-Rubyist, a natural question to ask is, "If
you didn't need easy access to names in or destined for the symbol
table, would Symbol objects exist in Ruby?" (Probably followed by "And
why do you need access to names in the symbol table, anyway?")
-A
On 12/29/05, Austin Ziegler <halostatue@gmail.com> wrote:
Hi --
Hi --
Just out of curiosity: can you describe how symbols would work if
they weren't surprising?They wouldn't exist, or they wouldn't be called symbols. If I'm referring to
an instance instead of a value, I could call it &variable as in C, or I could
call it :variable, but in that case I'd call it a reference, not a symbol.But it's not a reference; it's an object, of class Symbol. If you do:
s = :sym
then the variable s holds a reference to the object :sym, just as when
you do:a =
a holds a reference to that array.
This assertion by me seems to have been mercifully ignored in
subsequent discussion Actually, s = :sym doesn't produce a
reference to :sym; rather, s has the actual/immediate value :sym.
Anyway, the main (obscured) point was that symbols are not references.
I think one important key to understanding symbol objects is their
immediacy. When you see :sym, it's very similar to seeing an integer.
It *is* the object. What gets done with the object, or what methods
do or do not know how to use it to pry out methods or other things, is
secondary.
Here's where the s = :sym example should have been, since otherwise
I'm really talking about the literal constructor, which wasn't (i.e.,
shouldn't have been) the main point.
Anyway, I just wanted to ungarble that post a little
David
On Fri, 30 Dec 2005, dblack@wobblini.net wrote:
On Fri, 30 Dec 2005, Steve Litt wrote:
On Thursday 29 December 2005 10:16 am, dblack@wobblini.net wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
When I do the following:
attr_accessor :foo
For me, the colon was the most confusing part. Ignoring the colon, it
logically made sense to me that you'd want to do a:
attr_accessor foo1, foo2, foo3
Then, you realize "hey, I can't do that, because foo1, foo2, and foo3
represent local variables or methods or some object in the system".
Then I pull out my C/C++ hat and say:
attr_accessor "foo", "foo2", "foo3"
And that makes much more sense, because I have to pass the names somehow to
attr_acessor - and it's very common to using strings to do this in the C++
world.
Then you learn that every time Ruby sees a string it has to create a new
String object, and there's overhead involved. Instead, there's a special
class called Symbol which works kind of like a String, at least for these
purposes, and once you've ever created one it's always around.
Then it isn't profound until you see code like this:
1000.times do
some_object.getProperty("name")
end
and you realize that every time that gets executed a new "name" string has to
be created, and that's not so nice. But if you do a:
1000.times do
some_object.getProperty(:name)
end
Wow, that's much more fantastic.
And eventually you just "get it".
When we write:
attr_accessor :wilbur
what really happens is that the function attr_accessor() takes symbol :wilbur
as an argument, tacks on a @ to the string's value in order to make the true
class variable @wilbur,
That's an instance variable, not a class variable.
As Austin taught us yesterday, it doesn't make the variable either, just some methods.
and then writes a tiny get and set functions whose
names are wilbur, such that:my_object.wilbur = 22
puts my_object.wilburSo my initial comment that it seemed like magic is true only to the extent
that the "magic" performed by attr_accessor is to create the set and get
methods with the same name as the symbol that is its argument.
"Magic" to me is the tricky stuff and I don't see any of that here. We just told it the name for a method we wanted. You could easily code a pure Ruby replacement for the attr* methods, so it's really just a shortcut with Ruby doing some work for you. No magic there.
James Edward Gray II
On Dec 29, 2005, at 11:08 AM, Steve Litt wrote:
OK, let me see if I'm correctly understanding you.
Yep!
what really happens is that the function attr_accessor() takes symbol
:wilbur as an argument, tacks on a @ to the string's value in order to make
the true class variable @wilbur, and then writes a tiny get and set
functions whose names are wilbur, such that:my_object.wilbur = 22
puts my_object.wilburSo my initial comment that it seemed like magic is true only to the extent
that the "magic" performed by attr_accessor is to create the set and get
methods with the same name as the symbol that is its argument.Do I understand what you're saying?
That is exactly what happens.
And because that is what happens, one can write attr_accessor-like methods
oneself, if there is something additional/different that you want to have
happen. The symbol is just a tool.
Kirk Haines
On Thursday 29 December 2005 10:08 am, Steve Litt wrote:
They wouldn't exist, or they wouldn't be called symbols. If I'm
referring to an instance instead of a value, I could call it
&variable as in C, or I could call it :variable, but in that case
I'd call it a reference, not a symbol.It's not a reference. Symbols are much simpler than that. Really.
They are just an integer with some sequence of characters to
represent it, all wrapped up in an object.OK, let me see if I'm correctly understanding you.
:wilbur is an object. That object has two properties, which one could
call, in generic and not Ruby terms, a key and a value. The key is an
integer. The value is "wilbur". Neither the key nor the value can be
changed during the execution of the program. When we write:
No. :wilbur is an object. It has *one* property, itself. You can ask for
integer or string representations, but :wilbur's value is :wilbur and
there will only ever be one :wilbur.
attr_accessor :wilbur
what really happens is that the function attr_accessor() takes symbol
:wilbur as an argument, tacks on a @ to the string's value in order to
make the true class variable @wilbur, and then writes a tiny get and
set functions whose names are wilbur, such that:
Sort of. In the link that I posted for you earlier, you'll note that I
wrote an accessor generator (md5_accessor) which can be used to create
accessors that deal with variables named completely differently than the
accessors.
The method Module#attr_accessor will take the symbol and use it as a
name to create accessors (#wilbur and #wilbur=) that *coincidentally*
work on a variable of the same name. It doesn't *create* that variable.
my_object.wilbur = 22
puts my_object.wilburSo my initial comment that it seemed like magic is true only to the
extent that the "magic" performed by attr_accessor is to create the
set and get methods with the same name as the symbol that is its
argument.
You are correct in this last. The "magic" is in attr_accessor, not in
the Symbol. The Symbol is just a name.
-austin
On 29/12/05, Steve Litt <slitt@earthlink.net> wrote:
On Thursday 29 December 2005 11:20 am, Kirk Haines wrote:
On Thursday 29 December 2005 8:45 am, Steve Litt wrote:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Hi --
> Hi --
>
>
>>>
>>> Just out of curiosity: can you describe how symbols would work if
>>> they weren't surprising?
>>
>> They wouldn't exist, or they wouldn't be called symbols. If I'm referring
>> to
>> an instance instead of a value, I could call it &variable as in C, or I
>> could
>> call it :variable, but in that case I'd call it a reference, not a symbol.
>
> But it's not a reference; it's an object, of class Symbol. If you do:
>
> s = :sym
>
> then the variable s holds a reference to the object :sym, just as when
> you do:
>
> a =
>
> a holds a reference to that array.This assertion by me seems to have been mercifully ignored in
subsequent discussion
reference to :sym; rather, s has the actual/immediate value :sym.
Anyway, the main (obscured) point was that symbols are not references.
This is another bad aspect of Symbol explanations. Sooner or later
someone mentions 'immediate values' or 'internal symbol tables'.
While accurate (and in some cases, useful knowledge), these are a
big source of confusion and not in any way helpful to understanding
the fairly trivial function of Symbols 
> I think one important key to understanding symbol objects is their
> immediacy. When you see :sym, it's very similar to seeing an integer.
> It *is* the object. What gets done with the object, or what methods
> do or do not know how to use it to pry out methods or other things, is
> secondary.Here's where the s = :sym example should have been, since otherwise
I'm really talking about the literal constructor, which wasn't (i.e.,
shouldn't have been) the main point.Anyway, I just wanted to ungarble that post a little
David
E
On 2005.12.30 06:56, dblack@wobblini.net wrote:
On Fri, 30 Dec 2005, dblack@wobblini.net wrote:
> On Fri, 30 Dec 2005, Steve Litt wrote:
>> On Thursday 29 December 2005 10:16 am, dblack@wobblini.net wrote: