What is the difference between :foo and "foo"?

Ruby
61

Chad P. [email protected] writes:

Prior to this quote you provided, everything that has been said in
this discussion of Ruby symbols has seemed to indicate that there is
zero relationship between the two.

The first line of my journal (third post in this thread) already
mentions “The concept of symbols have been popular among the lisp
community…”.

So, there is not zero relationship between the two. Before coming to
ruby, I was already familiar with elisp and dabled some in CL. A quick
reading of the then scampy documentation of ruby Symbol revealed that
they are just different implementations of the same concept. But they
are not the same. ruby’s symbol is CL&elips symbol minus attributes
(symbol value, property list, etc.)

So tell me: Is a Ruby symbol basically just an object oriented
implementation of the Lisp concept of a symbol?

Yes: different implementations of the same concept. No: CL&elisp’s
Symbol has more functionalities.

If that’s the case, what’s up with all this tripe about “a symbol is
just a name” and so on?

Because it’s true? Because there are people who don’t have lisp
background who are not familiar with what symbol is? Because there are
people who thinks symbols are magical thingie?

I think these analogies are doing a disservice to people trying to
get a read on what a symbol is in Ruby.

This is true for all analogies. Different people are receptive to
different analogies. This simply means you are not receptive to the
analogy I made.

people are full of analogies and categorical statements
that don’t really explain anything

The basic message has always been clear: symbol is a mean for you, the
programmer, to name/identify entities. But somehow, people are having
difficulty understanding this and asked for more explanations. This is
when analogies and categorical statements came in.

Just as one does not dumbed down “‘everything’ is an object in ruby”,
which is a powerful ability, one should not dumbed down “symbols are
user-defined identifiers”. It’s just parts of learning curve.

Dumb down? No, never. Try explaining it, though.

As this and many other previous threads about symbol have shown,
explaining the concept of symbol is not easy.

While you’re at it, define “identifier” within this context.

To help people understanding the meaning of ‘identifier’, I’ve been
mentioning it together with ‘name’: ‘name/identify’ as in “It is just
a way to name/identify things”.

In any case, there is only one definition of identifier so context
should not influence the meaning of it:

From WordNet (r) 2.0 (August 2003) [wn]:

identifier
n : a symbol that establishes the identity of the one bearing it

YS.

62

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.29 23:37, Yohanes S.
[email protected] wrote:

What is the difference between :foo (a keyword) and “foo”(a string).
While, technically speaking, both of you are absolutely and
magically appearing before Christmas tree, parents resort to such
outlandish notion that that is the work of a joyful guy who has never
heard of razor in a red jumper suit and riding reinders-pulled sleigh
around the world in one night.

Some children outgrew that notion. Some don’t. Those that don’t would
either sulk for a long time about the demise of such a joyful guy, or
start to think their parents are liars and spend the next untold years
of their life learning enough Math and Physics to prove that it is
impossible for a guy like Santa Claus to visit all children in one
night.

Yes, I like the rationale presented. Perhaps I should have worded
differently: conflating Symbols with immutable strings (not Strings)
makes it easier to understand their function in ruby. Any ambiguity
resulting from this is far easier to correct than it is the assumption
that Symbols are identifiers or references or variables (rather than
values, which is the first thing anyone needs to know about Symbols).

As this thread quite well demonstrates,
a definition for Symbols is quite difficult to come up with.

A formal definition is difficult to formulate correctly, but what CLHS
has is good enough:

“Symbols are used for their object identity to name various entities
in Common Lisp, including (but not limited to) linguistic entities
such as variables and functions.” –
http://www.lisp.org/HyperSpec/Body/syscla_symbol.html#symbol

This makes no sense to someone just starting.

It is just a way to name/identify things. In RL, you name/identify
that collection of atoms ‘bird’, and another collection of atoms
‘cow’. In ruby, you name/identify an object ‘host’, and another object
‘port’. Just as you name parts of collection of atom that you named
‘bird’ ‘wings’, ‘legs’, ‘feathers’, etc., you name parts of a
Hashtable that you named ‘ServerConfig’ ‘host’, ‘port’.

This makes sense but, as you notice, you are using ‘strings’ in
your explanation :slight_smile:

Just as one does not dumbed down “‘everything’ is an object in ruby”,
which is a powerful ability, one should not dumbed down “symbols are
user-defined identifiers”. It’s just parts of learning curve.

Very good until this part. Symbols, most empathically, are not
identifiers (and I am quite sure this was merely a mistype/-thought
on your part).

To paraphrase fifteen thousand fourty-three mediocre
comedians over the last three centuries:

“A Symbol is like a word, a sentence, a phrase, a
description or, perhaps, a name. Except sometimes.”

YS.

E

“That sort of thing happens in bath tubs maybe. Not in real life.”
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDtEyGxvA1l6h+MUMRAnowAJsEyO25UhFG6VF6RbDZbzQ1XpKMWACfcEd4
HpUQm6vCasi8Yg5UPkzfAqE=
=hXPD
-----END PGP SIGNATURE-----

63

On 12/29/05, Chad P. [email protected] wrote:

Ever since this discussion started, I’ve wondered if there was some
relationship between Ruby symbols and Lisp symbols…
So tell me: Is a Ruby symbol basically just an object oriented
implementation of the Lisp concept of a symbol?

Yes, the concept of a symbol in Ruby is the same as in Lisp. Just as
similar as the concepts for integers, strings, arrays and other basic
constructs.

I think the confusion comes from two areas:

  1. Not many languages has ‘symbol’ as a distinct data type. Java has
    interned strings, which are pretty close to symbols for most practical
    purposes (symbols are atomic, immutable and unique, Java interned
    strings are just immutable and unique), but they are not a separate
    datatype.

  2. It is not immediately obvious why symbols are useful. Numbers and
    arrays/lists are easily explained as representing numbers and ‘a
    construct to hold multiple values’, but there is no such simple
    explanation for symbols. Not that I know of, anyway.

jf

64

Hi –

On Fri, 30 Dec 2005, [email protected] wrote:

to

a = []

a holds a reference to that array.

This assertion by me seems to have been mercifully ignored in
subsequent discussion :slight_smile: 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 :slight_smile:

David

–
David A. Black
[email protected]

“Ruby for Rails”, from Manning Publications, coming April 2006!

65

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.30 08:35, Steve L. [email protected] wrote:

just some methods.

My understanding of Ruby is the getters and setters it makes make the
variable, because the setter sets @wilber to its argument.

The instance variable is not created by the attr_* statement,
however. Only if you call obj.attribute = something will it
be created (unless you create it in #initialize or something).

irb(main):001:0> class Foo
irb(main):002:1> attr_accessor ‘bar’
irb(main):003:1> end
=> nil
irb(main):004:0> f = Foo.new
=> #Foo:0xb7de9be8
irb(main):005:0> f.inspect
=> “#Foo:0xb7de9be8”
irb(main):006:0> f.bar = 5
=> 5
irb(main):007:0> f.inspect
=> “#<Foo:0xb7de9be8 @bar=5>” # ← This here
irb(main):008:0>

SteveT

E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDtH2ZxvA1l6h+MUMRAudYAKCRQTHp/6p70j83waz8y3r56i4mwACeNkAW
5rX3d6mtf9XMuGZlu+zyk/U=
=ogE8
-----END PGP SIGNATURE-----

66

On Thursday 29 December 2005 01:03 pm, James Edward G. II wrote:
[clip]

class variable @wilbur,

That’s an instance variable, not a class variable.

I knew that :slight_smile: Skipping from Perl to C to C++ to Python to Ruby, I
sometimes
forget the terminology.

As Austin taught us yesterday, it doesn’t make the variable either,
just some methods.

My understanding of Ruby is the getters and setters it makes make the
variable, because the setter sets @wilber to its argument.

SteveT

Steve L.

[email protected]

67

On Fri, Dec 30, 2005 at 05:07:35AM +0900, Yohanes S. wrote:

Chad P. [email protected] writes:

If that’s the case, what’s up with all this tripe about “a symbol is
just a name” and so on?

Because it’s true? Because there are people who don’t have lisp
background who are not familiar with what symbol is? Because there are
people who thinks symbols are magical thingie?

It’s not really true, though, considering what a symbol is (according to
my current understanding). A symbol is an element of a hash table that
is often used as a name, and it is an (anonymous? not sure how to
qualify that) object. Calling it a “name” seems to be confusing common
use with actual nature, or premature explanation of an abstract way of
thinking about it, depending on how you mean “it is a name” when you say
it. Either way, it seems to be getting the cart before the horse.

I think these analogies are doing a disservice to people trying to
get a read on what a symbol is in Ruby.

This is true for all analogies. Different people are receptive to
different analogies. This simply means you are not receptive to the
analogy I made.

I think it’s probably more useful to start by describing the actual
functional nature of a symbol, then start in with the analogies if that
doesn’t make a lightbulb go on in the person’s head.

people are full of analogies and categorical statements
that don’t really explain anything

The basic message has always been clear: symbol is a mean for you, the
programmer, to name/identify entities. But somehow, people are having
difficulty understanding this and asked for more explanations. This is
when analogies and categorical statements came in.

“A means for you, the programmer, to name/identify entities” is not a
description of what a symbol is so much as a description of how you
can use it. It seems awfully odd to me that everything else in the
language tends to get described in terms of what it actually is under
the hood, then starts getting analogies only if the target of the
explanation doesn’t get it, while for some reason nobody starts an
explanation of symbols that way in Ruby.

For example: while saying that a method is “a verb” does help one to
“get” how verbs are used in the language, nobody really knows what a
method is until it’s explained that it’s a mini-algorithm whose
definition is part of a class definition, accessible by way of instances
thereof. As such, someone always starts explaining what a method is
under the hood pretty quickly when trying to get the point of a method
across in teaching OOP. With symbols, though, I keep seeing bland
assertions that a symbol is “just a name”, or “a name that is an
object”, or something like that, without any explanation of what a
symbol actually does behind the scenes.

I seem to have missed the blog post that mentioned the relationship to
Lisp methods, but even that didn’t really address the matter as clearly
as I would have expected.

From WordNet (r) 2.0 (August 2003) [wn]:

identifier
n : a symbol that establishes the identity of the one bearing it

. . . which, unfortunately, in no way explains what one does with a
“symbol” in a programming context in a helpful way.

A symbol is an element (or a reference to an element, though I hesitate
to use the term “reference” with its programming contextual baggage) in
a hash table. A hash table is, in short, a list maintained “by the
language” rather than by the user. From the programmer’s point of view,
this list essentially has only values, not keys, though from the
language’s point of view it most certainly has keys. This is primarily
useful for applying names to things, thus the common assertion that “a
symbol is a name”.

Is that close, or have I missed something?

–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]

“A script is what you give the actors. A program
is what you give the audience.” - Larry Wall

68

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.30 09:36, Chad P. [email protected] wrote:

It’s not really true, though, considering what a symbol is (according to
my current understanding). A symbol is an element of a hash table that
is often used as a name, and it is an (anonymous? not sure how to
qualify that) object. Calling it a “name” seems to be confusing common
use with actual nature, or premature explanation of an abstract way of
thinking about it, depending on how you mean “it is a name” when you say
it. Either way, it seems to be getting the cart before the horse.

Nope, Symbols have nothing to do with Hashes. They are often used
as Hash keys because they are descriptive: h[:foo] is better than
h[1] if one wants to convey some meaning with the key. In other
languages, you might use a string instead of a Symbol (and you
can, of course, do so in ruby as well: h[‘foo’]).

“A means for you, the programmer, to name/identify entities” is not a
definition is part of a class definition, accessible by way of instances

a hash table. A hash table is, in short, a list maintained “by the
language” rather than by the user. From the programmer’s point of view,
this list essentially has only values, not keys, though from the
language’s point of view it most certainly has keys. This is primarily
useful for applying names to things, thus the common assertion that “a
symbol is a name”.

Is that close, or have I missed something?

E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDtJmoxvA1l6h+MUMRApdyAJ4tpDcrx5X9ZuP2J9xn5lNLhZfbMQCfbYqG
x9YzyZMOlgYTH1d8ZyBy2OM=
=6asn
-----END PGP SIGNATURE-----

69

On Fri, Dec 30, 2005 at 10:42:33AM +0900, Eero S. wrote:

thinking about it, depending on how you mean “it is a name” when you say
it. Either way, it seems to be getting the cart before the horse.

Nope, Symbols have nothing to do with Hashes. They are often used
as Hash keys because they are descriptive: h[:foo] is better than
h[1] if one wants to convey some meaning with the key. In other
languages, you might use a string instead of a Symbol (and you
can, of course, do so in ruby as well: h[‘foo’]).

Apparently, a more significant distinction needs to be made between a
“hash table” in the symbol sense of the term and a “hash” in the sense
of an associative array.

–
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.

70

Austin Z. wrote:

The Symbol is just a name.

Er… a thing that /has/ a name. (That being, Symbol#to_s.)

A symbol’s just a thing. :apple == :apple. :apple.to_s == “apple”.
:apple.to_i == 23417. The end.*

AFAIK, you can use a String to do all the things you would do with a
Symbol (i.e. identify things)+, but using Symbols is more fun! (More
performant, possibly, for the purpose of static identifiers, and a
little less line noise, when used as the key to a hash, for example.
Plus, if you’re using a text editor with syntax highlighting, they’ll
show up a different color, which is fun.)

Devin

  • Though I’m not a very good one, I’m a mathematician at heart, so I
    like to define things by their properties.
  • This is because all the builtin methods that are meant to take a
    Symbol as a parameter tend to call its #== or #eql? or #hash or #to_s
    method (the properties of which String mimicks, to an isomorphism), or
    allow a String to be passed in its place (as is the case with attr_*,
    e.g.).
71

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.30 06:56, [email protected] wrote:

Just out of curiosity: can you describe how symbols would work if
s = :sym
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 :confused:

Anyway, I just wanted to ungarble that post a little :slight_smile:

David

E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDtJqOxvA1l6h+MUMRAqwhAKCatKyxn2DGqWoPGUyfIrxMIgLRWACeN1CV
yZoLjAC5NQbaZY7mUfYZh/0=
=Z5I7
-----END PGP SIGNATURE-----

72

Devin M. wrote:

Austin Z. wrote:

The Symbol is just a name.

Er… a thing that /has/ a name. (That being, Symbol#to_s.)

OK, well, I RTFA, and sorry for blatantly contradicting what was an
intentional choice of words (and not, as I had thought, a slip-up)
without reason. Anyways, to quote you:

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.

Calling it a “name” is just another analogy. Its name is its String
representation, just as Module#name == Module#to_s (for non-singletons).
Rather, :jazz is :jazz is :jazz. There is no reducing it to other
concepts.

Devin
Yeah, I know, total 540.

73

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.30 11:38, Chad P. [email protected] wrote:

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 :confused:

I disagree. If the underlying semantic mechanism of a symbol isn’t
understood, symbols won’t be understood.

Neither of the above is in any way essential to understanding the
concept of a Symbol (as it appears in ruby), they are implementation
details. Symbols could perform the exact same function they do now
even as a user-defined construct. I do not think it is at all necessary
to know either of these facts to be able to use Symbols.

I am, of course, only speaking from my own point of view but I
do have some experience in introducing ruby Symbols to new users.
Doing that I have found that it is simplest to introduce Symbols
as names or descriptive values, similar to regular strings in that
respect. This but-what-are-they-for foundation established it is
easy to introduce additional implementation details.

One size definitely does not fit all; people learn differently.

  1. Symbols are values.
    :foo is like ‘foo’ or 2 or f = FooObject.new

  2. Symbols are used to name, describe or label things.
    cd_drive_type = :dvd_rom
    socks = my_closet[:sock_drawer]

  3. Common usages.
    object.send :method_name, parameter # Could use ‘method_name’
    attr_accessor :property1, :property2 # Could use ‘property1’ etc.

  4. Implementation details.

E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDtMJTxvA1l6h+MUMRApnZAJ9O8dm9GAw+NTVT5AibfIBWPqFzmgCglyXm
i0rCU+NMdYvNP7b1GA5wg+I=
=WSB5
-----END PGP SIGNATURE-----

74

On Fri, Dec 30, 2005 at 10:46:23AM +0900, Eero S. wrote:

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 :confused:

I disagree. If the underlying semantic mechanism of a symbol isn’t
understood, symbols won’t be understood.

–
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.

75

To whom who asked this question, open your console / terminal and type:

ri Symbol

Then type:

ri String

~ ryan ~

76

On Dec 29, 2005, at 9:38 PM, Chad P. wrote:

I disagree. If the underlying semantic mechanism of a symbol isn’t
understood, symbols won’t be understood.

I think one of the hardest things to explain/comprehend
about symbols is that the only semantics associated
with a symbol is that there is a one to one mapping from a symbol
object to a sequence of characters. It is this isomorphism that
is the useful (and only) property of symbols.

The sequence of characters can be specified by
a literal symbol identifier (e.g. :red, :white, :“navy blue”), in which
case the mapping to a symbol reference is done by the parser, or the
sequence of characters can be specified by an instance of a String
(“red”) and mapped to a symbol reference via the String#to_sym method
(“red”.to_sym)

This is entirely analogous to how integer literals are handled.
A sequence of characters (ascii 51, ascii 53) is mapped by the
parser to a reference to an object that has the properties of the
number 35.
You can also take an instance of String (“35”) and have String#to_i
map it to a reference of an object that has the properties of the
number 35
(“35”.to_i). That doesn’t mean that the string “35” is the number
35, just that
there is an isomorphism from a sequence of digits to references to
integers.

I’ve been careful to say ‘reference to an object’ and not ‘object’
because
the values stored in variables or constants are references to
objects, not
the objects themselves. For some classes, such as Fixnum, Float, or
Symbol, the
objects are implicit and Ruby derives them from the reference itself
when needed
and for other objects, say String or Array, the reference is used to
locate the
object in memory.

With integers, the referenced object associated with the sequence of
digits
has nice numerical properties but symbols have no properties
other than their property of being uniquely identifiable.

So when your intent is to reference objects with distinct identities
but no
other properties, Symbols are the way to go. You could use integers
of course, they also are unique and easily represented by
a sequence of characters, but which is more meaningful?

flavors = [1,2,3]
flavors = [:chocolate, :vanilla, :strawberry]

I think symbols get confused with methods, and classes, and instance
variables
because the concept of identity is just as useful to an application
programmer
as to a language implementor (that and the PickAxe incorrectly says
they are
directly related). Ruby just happens to expose the identity of various
language internals using the same mechanism (symbols) as is available
to the
application programmer. No one gets confused when an Array reports
its size
using the integer 5 even though the programmer may have also used the
number
5 to limit the size of a zipcode field. Similarly the idea that Ruby
might
use the symbol identified by :size to uniquely identify an instance
method
in the class Array shouldn’t be confused with a programmer using the
same
symbol to identify a method in a class they have defined. The symbol
is the
same in both cases but the context is different so there is no
ambiguity.

77

Chad P. [email protected] writes:

Calling it a “name” seems to be confusing common use with actual
nature, or premature explanation of an abstract way of thinking
about it, depending on how you mean “it is a name” when you say it.

Well, what can I say? Symbol is really meant to represent a
name/identifier.

Let’s stop with analogies since obviously we are not
analogy-compatible, and get on with the concretes.

What is 1? A way to represent the number one. You said a way, what
others are there? 0x1, \001, “1”. However, one does not use “1” to
represent the number one even if one doesn’t plan to do any arithmetic
operations on that number because that representation is
ambiguous. Does he mean “1” as in number one or as in the character
“1”?

What is :server? A way to represent the name/identifier
server. What others are there? “server” is another one. But it is
also ambigious. Does he mean the name/identifier server or the
character sequence “s”,“e”,“r”,“v”,“e”,“r”?

I can see no way to describe 1 without involving number. Similarly, I
can see no way to describe :server without involving
name/identifier. Perhaps you can.

“A means for you, the programmer, to name/identify entities” is not a
description of what a symbol is so much as a description of how you
can use it.

I really am not sure what you are saying there. That sentence
describes what a symbol is. That sentence does not describe/prescribe
how to use it.

Here, let me paraphrase my sentence: “[Symbol is] a means for you, the
programmer, to [represent the] name/identit[y] of entities”. Did I
manage to preserve the meaning? Let’s do word substitution. “Number
is a means for you, the programmer, to represent numbers”. In no way
am I describing/prescribing how to use instances of Number.

object", or something like that, without any explanation of what a
symbol actually does behind the scenes.

This is precisely the kind of explanation that I objected when
explaining what a symbol is to a newcomer. Any explanation that refer
to the implementation is doomed to be short-lived. There are many ways
to implement the class Symbol and the concept of symbol.

Do you explain what number does behind the scenes to someone asking
‘What is a number?’ Do you explain that ruby maps number less than
2^31-1 directly to native integer format? Quick question, then: does
this still hold on a 64-bit machine? How about in ruby 2.0? Will
Number behave differently and is used to represent different thing
there simply because what goes on behind the scene has changed?

If one is interested in how something is implemented in a specific
environment, one should ask for that (and there are posts in this
thread dwelving into how Symbol is implemented in current ruby VM).

In any case, if someone can give me a description of what 1 is without
involving number, then I’ll show you a description of what symbol is
without involving name/identifier.

YS.

78

For the heck of it, I decided to come up with my own Symbol analogy.
Caveat reader:

A symbol is a bubble. In Ruby-land, there is this ever-present ether
wherein lies an abundance of bubbles.

<picture of a bunch of bubbles, each with a symbol literal inside –
feel free to Gimp it into existence – here’s a starter kit:
scrapbookerie.com>

Every symbol you could ever want is out there, in the ether, bubbling
along. For every name, there is a single bubble. For every bubble, there
is a single name.

When you assign +x = :mr_t+, as with all variable assignments, you’re
pointing x to the :mr_t object. Here, you’re pointing at that bubble
that the Ruby interpreter recognizes as :mr_t. For plausability reasons,
the Ruby interpreter blows the :mr_t bubble the first time you mention
its name, but for your sake, you can assume that the :mr_t bubble has
always existed and always will exist – it’s just there, floating in the
ether, waiting to be pointed to.

So from that description right there, we already know one thing we can
do with bubbles–er, Symbols–determine equality. Are these two
variables pointing to the same bubble? Find me the Hash value whose
associated key is this bubble I’m pointing to right now. For programming
convenience, these bubbles have names associated with them, but as far
as your code is concerned, they’re just bubbles. This is the magic
behind {:server => ‘localhost’, :port => 80}, etc.

The other (principal) thing you can do with a bubble–eh, Symbol–is
find out its name at runtime (thanks to #to_s or #id2name). Thus,
attr_accessor :mcklellan is born. I’m passing along a pointer to the
:mcklellan bubble. attr_accessor follows the pointer, talks to that
bubble, asks it what its name is, and uses that information to define
some methods. Here, :mcklellan is just used as a fancy shorthand for
‘mcklellan’. (It happens to be one I like, but I digress…)

So, uh, yeah. That’s it. The End.

Ha, yeah, so that description is probably more unsettling than settling,
but maybe it’ll plant a seed of wisdom, or whatnot. Plus, I can rest
easy, now that I’ve solved everybody’s problems.

Devin
Did I really just digress into “The End”?

79

Heh, one of my emails to the list got eaten (by a grue?). Let’s try this
again:

Devin M. wrote:

Austin Z. wrote:

The Symbol is just a name.

Er… a thing that /has/ a name. (That being, Symbol#to_s.)

OK, well, I RTFA, and sorry for blatantly contradicting what was an
intentional choice of words (and not, as I had thought, a slip-up)
without reason. Anyways, to quote you:

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.

Calling it a “name” is just another analogy. Its name is its String
representation, just as Module#name == Module#to_s (for non-singletons).
Rather, :jazz is :jazz is :jazz. There is no reducing it to other
concepts.

Devin
Yeah, I know, total 540.

80

On 29/12/05, Devin M. [email protected] wrote:

Austin Z. wrote:

The Symbol is just a name.
Er… a thing that /has/ a name. (That being, Symbol#to_s.)

No, I think that the essential property of a Symbol is that it is an
object that is a name:

keep = Symbol.all_symbols
quuxl = nil
puts Symbol.all_symbols - keep

You’ll see that :quuxl is there. You can get a string representation
of that name (:quuxl.to_s) or an integer representation of that name
(:quuxl.to_i), but the canonical representation of that name is the
Symbol itself (:quuxl). Sure, you could get pedantically
philosophical, but the you’d be saying that 1 really isn’t the number,
it’s a thing that represents a quantity of one.

For all practical purposes, Symbols are atomic in the sense that they
are themselves. Who cares how it’s actually represented in the
implementation? That can change. The fundamental nature of a Symbol is
that :quuxl will always be :quuxl and never anything else. Consider
these two IRB sessions:

irb(main):001:0> :bar.to_i
=> 23417
irb(main):002:0> :quuxl.to_i
=> 23425
irb(main):003:0>

irb(main):001:0> :quuxl.to_i
=> 23417
irb(main):002:0> :bar.to_i
=> 23425
irb(main):003:0>

A Symbol, like a number, is immediate and is identified by itself.

-austin