The original poster, Surgeon, wrote only two comments.
This is his second, sixty comments ago:
Oh, so many replies to my poor question! What a wonderful community!
I guess, he was forgotten somewhere around five 
Next comment will be number 100!
Christer
On 12/30/05, [email protected] [email protected] wrote:
Gary “did I submit the 100th message?” Wright
Actually. Not according to ruby-forum. The message before yours was
the 100th 
But nothin’ wrong with being 101.
Gary W., Symbols 101. Hey, didn’t you teach that class a couple
weeks ago? 
-Greg (102… i think)
On Dec 30, 2005, at 1:08 PM, Christer N. wrote:
The original poster, Surgeon, wrote only two comments.
This is his second, sixty comments ago:Oh, so many replies to my poor question! What a wonderful community!
I guess, he was forgotten somewhere around five
Next comment will be number 100!
Yikes. I hope we don’t start behaving like the Slashdot community
where everyone races to post the message “this is the first message”.
Gary “did I submit the 100th message?” Wright
On Friday 30 December 2005 10:35 am, Steve L. wrote:
[clip]
With all the controversy, including some piping to a killfile, the issue
isn’t my depth of digging, it’s either everyone’s depth of digging, or
it’s an issue of :symbols being a particularly surprising element of Ruby.
I haven’t heard this level of disagreement about blocks, methods, iterators
and the like. Heck, for two cents I’ll document it myself!SteveT
The Ruby N. Guide to Symbols is here:
SteveT
Steve L.
On Friday 30 December 2005 1:03 pm, Austin Z. wrote:
Please edit your guide, as it is not correct when it says:
A Ruby symbol is a thing that has both a number (integer) and a string.
This is not correct in any way. If you leave it as “A Ruby Symbol is a
thing”, you’re fine. But when you say that it “has” a number and a
string, you are incorrect. Symbols are not composed of the integer or
string values that you can convert Symbols to; they just are. The
value of a Symbol is not its String value or its Fixnum value, but
itself.
I think that I am probably the source for this confusion, and I am
guilty of
not clarifying further what I meant.
:foo is a symbol. The string representation of :foo is ‘foo’.
:foo.to_s
:foo also has an integer that id, found with #object_id:
:foo.object_id
This is no different than any other object. What is different is this:
irb(main):001:0> ‘foo’.object_id
=> -609482574
irb(main):002:0> ‘foo’.object_id
=> -609486184
irb(main):003:0> ‘foo’.object_id
=> -609489724
The id changes because each ‘foo’ is a different object.
irb(main):004:0> :foo.object_id
=> 3957006
irb(main):005:0> :foo.object_id
=> 3957006
irb(main):006:0> :foo.object_id
=> 3957006
The id doesn’t change because :foo is just :foo – it’s the same object
every
time.
Kirk H.
On 30/12/05, Steve L. [email protected] wrote:
The Ruby N. Guide to Symbols is here:
Steve:
Please edit your guide, as it is not correct when it says:
A Ruby symbol is a thing that has both a number (integer) and a
string.
This is not correct in any way. If you leave it as “A Ruby Symbol is a
thing”, you’re fine. But when you say that it “has” a number and a
string, you are incorrect. Symbols are not composed of the integer or
string values that you can convert Symbols to; they just are. The
value of a Symbol is not its String value or its Fixnum value, but
itself.
I strongly recommend rewriting your guide from that perspective,
because you are likely to greatly increase the confusion of newbies.
If you would like, I can see about possibly helping you edit this or
coauthor it such that it might become a useful article to be published
at Ruby Code & Style to explain where Symbols can be used and what
they are. Ultimately, though, trying to dig into the internals of
Symbols misses the point – it’s just something that represents
itself.
-austin
On Friday 30 December 2005 03:03 pm, Austin Z. wrote:
A Ruby symbol is a thing that has both a number (integer) and a string.
This is not correct in any way. If you leave it as “A Ruby Symbol is a
thing”, you’re fine. But when you say that it “has” a number and a
string, you are incorrect. Symbols are not composed of the integer or
string values that you can convert Symbols to; they just are. The
value of a Symbol is not its String value or its Fixnum value, but
itself.
Hi Austin,
I have no idea of the internal representation, but I do know when I use
to_s
on a symbol I get a string, and when I use to_i on that same symbol I
get an
integer, so in a generic, non-ruby-dependent way, it has an integer and
a
string. If it didn’t “have” or “possess” or “be cognisant of” both the
integer and the string, I wouldn’t be able to deduce the string and
integer
with to_s and to_i.
Once again, this document is not meant for Ruby veterans, and its
intention
was never to explain symbols in Ruby terms. This document does not
pretend to
portray how Ruby really stores a symbol, or even what a symbol is beyond
the
basics necessary to use it. This document simply presents a model that
is
handy in forming a very basic understanding leading to correct use of
symbols.
Light is something more complicated than either a wave or a particle,
and yet
discussing it as waves and particles helped me understand light to some
degree in high school physics class. Had I majored in Physics on
college, I
would have learned where reality departed from the wave and particle
models.
I strongly recommend rewriting your guide from that perspective,
because you are likely to greatly increase the confusion of newbies.
I think it will decrease newbie confusion about how to use symbols,
and how
to read other peoples code containing symbols.
If somebody could show me some actual code where the model I represent
in the
document leads to somebody mis-coding a program, I’ll reconsider.
As far as the document’s departure from actual Ruby implementation, the
doc
warns up front that this does not necessarily conform to actual
implementation in Ruby.
If you would like, I can see about possibly helping you edit this or
coauthor it such that it might become a useful article to be published
at Ruby Code & Style to explain where Symbols can be used and what
they are.
Ultimately, though, trying to dig into the internals of
Symbols misses the point
That’s exactly my motivation for writing it the way it was written.
Thinking
about the Ruby internals at too early a stage muddies the water.
– it’s just something that represents
itself.
That’s true, but it’s not sufficient to help a newbie understand code
containing symbols, nor is it sufficient to help a newbie.
To summarize, I’m not for a moment disputing your portrayal of Ruby’s
implementation of symbols. I’m simply saying that the model I present
in
the document enables Ruby newbies to quickly understand, on a basic
level,
other peoples code that uses symbols, and enable them to use symbols
correctly in their own code.
Thanks
SteveT
Steve L.
On Friday 30 December 2005 03:29 pm, Kirk H. wrote:
value of a Symbol is not its String value or its Fixnum value, but
:every time.
Kirk H.
Hi Kirk,
I could swear that’s exactly what I said in the Ruby N. Guide to
Symbols.
I like your code-centric way of saying it, though.
SteveT
Steve L.
On Friday 30 December 2005 1:40 pm, Steve L. wrote:
I could swear that’s exactly what I said in the Ruby N. Guide to
Symbols. I like your code-centric way of saying it, though.
It could be what you said. I am leaving to get a needle stuck into
my arm
in a moment and haven’t read more than Austin’s comment about your
writeup,
so far.
Kirk H.
I have no idea of the internal representation, but I do know when I use
to_s on a symbol I get a string, and when I use to_i on that same symbol I
get an integer, so in a generic, non-ruby-dependent way, it has an integer
and a string. If it didn’t “have” or “possess” or “be cognisant of” both
the integer and the string, I wouldn’t be able to deduce the string and
integer with to_s and to_i.
I think the nomenclature of “has” isn’t valid because the symbol doesn’t
contain those things. Much like
a = “53”
a.to_i
=> 53
“a” doesn’t contain an integer. It does, however, contain a method that
allows you to convert it to an integer representation.
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”.
On Friday 30 December 2005 03:50 pm, Caleb T. wrote:
a = “53”
a.to_i=> 53
“a” doesn’t contain an integer. It does, however, contain a method that
allows you to convert it to an integer representation.
I understand what you’re saying Caleb. Austin – is that what you meant?
SteveT
Steve L.
On Sat, Dec 31, 2005 at 12:55:55AM +0900, Austin Z. wrote:
Hopefully that’s a bit clearer. 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.
–
Chad P. [ 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.
On 30/12/05, Steve L. [email protected] wrote:
a = “53”
a.to_i=> 53
“a” doesn’t contain an integer. It does, however, contain a method that
allows you to convert it to an integer representation.I understand what you’re saying Caleb. Austin – is that what you meant?
Yes. I’ve just sent you a VERY lengthy VERY critical review of your
document that emphasizes that it is a conversion at all times. Symbols
have neither string nor integer values, but has converters.
-austin
On Dec 30, 2005, at 5:19 PM, Chad P. wrote:
Note: This reply is sent directly to you, not to the list.
It was sent to both, actually.
James Edward G. II
Note: This reply is sent directly to you, not to the list.
On Sat, Dec 31, 2005 at 04:51:22AM +0900, Steve L. wrote:
The Ruby N. Guide to Symbols is here:
Excellent. Hopefully, I’m not overstepping myself by sending critiques,
but I have some suggestions:
The third paragraph kinda comes across as apologetic and hedging too
much. I thought about possible ways to rephrase it, but ultimately, I
think it would best be simply deleted. It doesn’t seem to actually
serve any useful purpose within the text of the tutorial.
The “What do they resemble in other languages?” should probably have
something in it, or be removed entirely without any reference to
resembling something in another language. You might consider making a
note about it being a work in progress, with a solicitation for comments
from readers who understand symbols about what they resemble from other
languages. If you do so, I’d recommend a very strong disclaimer to the
effect that resemblance is not the same as equivalency, and one should
take care in thinking of symbols as being similar to features in other
languages. In particular, you might mention:
a. Ruby symbols bear a superficial resemblance to barewords in
Perl, but are not much the same in practice.
b. Ruby symbols bear some resemblance to globs, though globs are
limited to use in relation to filehandles. By extension (and,
unsurprisingly) Ruby symbols also bear some resemblance to the
treatment of globs by the Perl module, Symbol, though it is only an
unreasonable facsimile of Ruby symbols because it is just a wrapper
for globs meant to make them more symbol-like in appearance.
c. Ruby symbols are similar to Lisp symbols, with the exception
that in addition to the characteristics of symbols in Lisp, they are
also objects in Ruby.
In “What are symbols?” you might consider drawing a direct
comparison between symbols and numbers (or even integers), in particular
as regards their relationship to strings. What I mean by this is that
you might say:
:symbol is to “symbol” as 1 is to “1”
Another possible section to include in your tutorial might actually
be a transition between the “What do they resemble in other languages?”
and “What are symbols?” sections: “What else do they resemble in Ruby?”
This occurs to me mostly as a (perhaps better) place to put my
comparison of symbols to numbers:
:symbol is to “symbol” as 1 is to “1”
In the “What are symbols?” section, when you bring up the results of
:steve.to_i, you might consider mentioning that the integer to which a
symbol is translated will be different in one program than in another,
and that the reason for this is that Ruby is simply using this integer
to keep track of the symbol internally, so it’s not a “random” number.
As a point of academic interest, this is because there’s a hash table in
which Ruby keeps track of these things, essentially using integers as
keys by which it keeps track of symbols, though I’m not sure that’s
something useful to an explanation of symbols at the level of this
tutorial. In short, I think it’s a good idea to mention something about
why :symbol.to_i produces an immutably set integer so that new Rubyists
won’t start making assumptions about where the number arises and try to
use it improperly as a result.
When you talk about capitalizing a string derived from a symbol, you
might also mention that you could, rather than using
:steve.to_s.capitalize, just use :Steve. This is more in keeping with
the point of a symbol, I think, if your capitalized version isn’t meant
to have a direct connection in the program logic to :steve itself. If
it were me writing it, I might end up using an example that looks like
this, to demonstrate that from a program output perspective, both
approaches render the same result:
#!/usr/bin/env ruby
mystring = :steve.to_s.capitalize
puts mystring
puts :Steve
I think you forgot a colon in “A symbol is not (Just) a Name”.
Either that, or I didn’t understand what you were trying to demonstrate.
You also seem to have forgotten a closing parenthesis in the same
section. I might also suggest replacing the words “to hold” with “as”,
when discussing the practical relationship between a symbol and a name,
since a symbol technically doesn’t “hold” anything – though I only
recommend the substitution, really, to forestall potential criticism.
In “What can symbols do for you?” you might consider, in addition to
mentioning that you can create a string from one using .to_s, revisiting
the fact that a symbol is essentially treated as a string when used in a
string context (such as puts :symbol).
In “What are the advantages and disadvantages of symbols?” you say
“The granddaddy of all advantages is also the granddaddy of
advantages:”. I don’t get it, unless that was a typo.
You might also mention another advantage of symbols, which pertains
more to metaprogramming than to the sort of programming with which most
programmers are familiar: symbols don’t exist until you refer to them,
but when you do so, they spring into existence as though they had always
been there. This allows for programming logic that acts almost like
time-travel, in that you can do something with a thing that acts like
it has always existed without having to create it before you use it, and
that thing can be any arbitrary thing at all, rather than having to be
part of some intrinsic language construct. This is exactly the sort of
dynamism that makes Lisp (and, now, Ruby) so powerful.
I’m sure you’ve noticed by now, but you might consider editing the
first sentence of the “Summary” to say that symbols prompted a thread of
“more than 100 posts” rather than saying it was a “97 post thread”.
Hopefully you won’t take any of this amiss. Overall, I’m impressed with
the tutorial, and only recommend alterations because I’m pretty sure you
can handle it, and I would like to see your tutorial be the best it can
be. Use or ignore the foregoing advice at your leisure, of course.
–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]
This sig for rent: a Signify v1.14 production from
On Sat, Dec 31, 2005 at 08:19:49AM +0900, Chad P. wrote:
Note: This reply is sent directly to you, not to the list.
Oops.
–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]
“Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts.” - Paul Graham
On Sat, Dec 31, 2005 at 05:03:20AM +0900, Austin Z. wrote:
itself.
That depends on how one understands the word “has” in this context. For
instance, as you say, a symbol does not contain or consist of parts
including an integer and a string. On the other hand, a symbol “has”
associated with it, if and when you place it within the correct context,
both a string and an integer. The string association springs into being
when one uses .to_s, and the integer association exists because of the
hash table in which symbols are stored “behind the scenes”. Actually,
one might make a case for the string association existing from the word
go, but I have no idea how that could be explained succinctly.
If you would like, I can see about possibly helping you edit this or
coauthor it such that it might become a useful article to be published
at Ruby Code & Style to explain where Symbols can be used and what
they are. Ultimately, though, trying to dig into the internals of
Symbols misses the point – it’s just something that represents
itself.
I’m afraid I disagree with the implication that what strings do from
Ruby’s perspective is not useful information. Simply saying that a
symbol is “something that represents itself” might explain it perfectly
to you, as it might to legions of (for instance) Python programmers used
to using names rather than variables, or whatever it is that Python
programmers do, but it clearly didn’t help Steve or me very much. This
indicates that another approach is needed, at least sometimes, and that
approach might involve an understanding of why symbols act the way
they do in context so that symbol behavior in code can be predicted when
one is writing said code.
. . . and please don’t point out that symbols don’t “do” anything, or
have any “behavior”. You (should) know what I mean from context.
–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]
“Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts.” - Paul Graham
On Sat, Dec 31, 2005 at 08:26:02AM +0900, James Edward G. II wrote:
On Dec 30, 2005, at 5:19 PM, Chad P. wrote:
Note: This reply is sent directly to you, not to the list.
It was sent to both, actually.
Yeah, I noticed. I’ll go have my time-out in the corner now.
–
Chad P. [ 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.
On 30/12/05, Chad P. [email protected] wrote:
. . . and please don’t point out that symbols don’t “do” anything, or
have any “behavior”. You (should) know what I mean from context.
Except that by trying to suggest that Symbols “act” a particular way
is nonsense. They don’t do anything, they don’t have any behaviour;
they just are simple names. In 99% of all uses of Symbols, that’s
absolutely all that matters.
Do I really care that they’re stored in Ruby on the internal symbol
table?
No. Not in the last two and a half years have I cared once. Sure, it’s
nice that they only end up representing a single object, but I really
have never cared how they’re represented. I use them for what they
are, not how they’re implemented. And what they are, is names.
-austin
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs