On Friday 30 December 2005 03:03 pm, Austin Ziegler wrote:
> On 30/12/05, Steve Litt <slitt / earthlink.net> wrote:
> > On Friday 30 December 2005 10:35 am, Steve Litt 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 Newbie Guide to Symbols is here:
> >
> > http://www.troubleshooters.com/codecorn/ruby/symbols.htm
>
> 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.

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 Litt
http://www.troubleshooters.com
slitt / troubleshooters.com