Steve Litt <slitt@earthlink.net> writes:
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.
That just means you didn't dig deep enough into Ruby (yet). 
dblack:
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.
My understanding of things so far was that :sym and 3 are immediate values,
and after writing
a, b = :sym, 3
a is a reference to :sym and b is a reference to 3.
Have I been wrong all the time?
Malte
[clip]
> class variable @wilbur,
That's an instance variable, not a class variable.
I knew that 
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 Litt
slitt@troubleshooters.com
On Thursday 29 December 2005 01:03 pm, James Edward Gray II wrote:
Austin Ziegler 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.).
I disagree. If the underlying semantic mechanism of a symbol isn't
understood, symbols won't be understood.
On Fri, Dec 30, 2005 at 10:46:23AM +0900, Eero Saynatkari wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On 2005.12.30 06:56, dblack@wobblini.net wrote:
>
> 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
--
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.
Hi --
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1This 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
"Immediate value" is not a useless or arcane notion. (And I did *not*
mention the internal symbol table In fact, understanding that
some variable assignments result in variables that hold immediate
values, and others result in variables that hold references, is quite
important, if you want to understand, for example, the whole lack of
post-increment operator thing (i.e., the fact that, given x = 1, x++
and 1++ are the same expression, etc.).
I agree that part of the problem with people understanding Symbols is
the tendency to expect, and look for, more than is there -- but I'd
maintain that to understand Ruby identifiers fully, you really need to
be aware of the (not terribly difficult) notion of immediate values
vs. references.
David
On Fri, 30 Dec 2005, Eero Saynatkari wrote:
On Fri, 30 Dec 2005, dblack@wobblini.net wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
Then neither did the 20+ other people, some long time Ruby users, who couldn't
put forth an explanation clear enough to settle the issue amongst the
majority.
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
Steve Litt
slitt@troubleshooters.com
On Friday 30 December 2005 08:06 am, Christian Neukirchen wrote:
Steve Litt <slitt@earthlink.net> writes:
> 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.That just means you didn't dig deep enough into Ruby (yet).
I wonder that too. What about:
a, b = :sym, :sym
I guess a and b hold separate references to the same object, much as if I did
a, b = 4, 4
That was the basis for my mentioning literal fixnums earlier in the ':foo and "foo"' thread, but now I wonder if I'm in fact wrong (again ;)).
Basically I suppose I'm confused about assignment by value or reference. I though Ruby was pass by reference, with references passed by value, no matter what?
On Fri, 30 Dec 2005 13:05:48 -0000, Malte Milatz <malte__@gmx-topmail.de> wrote:
dblack:
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.My understanding of things so far was that :sym and 3 are immediate values,
and after writing
a, b = :sym, 3
a is a reference to :sym and b is a reference to 3.Have I been wrong all the time?
--
Ross Bamford - rosco@roscopeco.remove.co.uk
Malte Milatz <malte__@gmx-topmail.de> writes:
dblack:
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.My understanding of things so far was that :sym and 3 are immediate values,
and after writing
a, b = :sym, 3
a is a reference to :sym and b is a reference to 3.
In the current implementation, no. It doesn't matter to the
programmer, though.
Have I been wrong all the time?
Malte
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
[clip]
> > class variable @wilbur,
>
> That's an instance variable, not a class variable.I knew that
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.
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
On 2005.12.30 08:35, Steve Litt <slitt@earthlink.net> wrote:
On Thursday 29 December 2005 01:03 pm, James Edward Gray II wrote:
Devin Mullins wrote:
Austin Ziegler 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.
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
On 2005.12.30 11:38, Chad Perrin <perrin@apotheon.com> wrote:
On Fri, Dec 30, 2005 at 10:46:23AM +0900, Eero Saynatkari wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2005.12.30 06:56, dblack@wobblini.net wrote:
> >
> > 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 SymbolsI 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.
On Dec 29, 2005, at 9:38 PM, Chad Perrin wrote:
I disagree. If the underlying semantic mechanism of a symbol isn't
understood, symbols won't be understood.
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
On 29/12/05, Devin Mullins <twifkak@comcast.net> wrote:
Austin Ziegler wrote:
>The Symbol is just a name.
Er... a thing that /has/ a name. (That being, Symbol#to_s.)
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Steve Litt <slitt@earthlink.net> writes:
Steve Litt <slitt@earthlink.net> writes:
> 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.That just means you didn't dig deep enough into Ruby (yet).
Then neither did the 20+ other people, some long time Ruby users, who couldn't
put forth an explanation clear enough to settle the issue amongst the
majority.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!
Oh, I'm sorry. I think you got me wrong. I was refering to the "most
suprising element" for you. There are mystic parts of ruby that are
far more suprising. Personally, I don't know why people have such big
problems with Symbol, and I'll probably not ever understand. Just
take them for granted and use them.
On Friday 30 December 2005 08:06 am, Christian Neukirchen wrote:
SteveT
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
[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 Newbie Guide to Symbols is here:
SteveT
Steve Litt
slitt@troubleshooters.com
On Friday 30 December 2005 10:35 am, Steve Litt wrote:
Christian Neukirchen:
Malte Milatz:
My understanding of things so far was that :sym and 3 are immediate
values, and after writing
a, b = :sym, 3
a is a reference to :sym and b is a reference to 3.In the current implementation, no. It doesn't matter to the programmer,
though.
I'm happy I'm not forced to dig into the details of Ruby's immediate
values...
Malte
> My understanding of things so far was that :sym and 3 are immediate
> values,
> and after writing
> a, b = :sym, 3
> a is a reference to :sym and b is a reference to 3.
> Have I been wrong all the time?I wonder that too. What about:
a, b = :sym, :sym
I guess a and b hold separate references to the same object, much as if I
did
a, b = 4, 4
Basically I suppose I'm confused about assignment by value or reference. I
though Ruby was pass by reference, with references passed by value, no
matter what?
The 'pass by reference/value' terminology isn't used much in Ruby (or
in Smalltalk, Java, Python...), from the programmer's point of view
there's only one type of assignment and parameter passing.
But technically, a variable can hold either a reference to an object
or an immediate value. All normal objects are assigned by reference,
so in
a=Object.new
or
a="some string"
'a' holds a reference. The reference is a pointer to the object's
location in memory.
Fixnums and a few other special types (symbols, true/false/nil,
floats?) are assigned as immediate values: Instead of storing a
pointer (or reference) to the value object, the variable stores the
value directly. So in
a=4
'a' does not hold a reference, technically speaking, but rather the
immediate value 4.
This is an implementation issue, and is done for efficiency.
But the difference is largely transparent to the programmer, so I
guess it's mostly of interest to those who want to know how the
language works behind the scenes.
jf
To whom who asked this question, open your console / terminal and type:
ri Symbol
Then type:
ri String
~ ryan ~
Heh, one of my emails to the list got eaten (by a grue?). Let's try this again:
Devin Mullins wrote:
Austin Ziegler 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.
