From: Rick DeNatale <rick.denatale@...>
Date: 2007-05-16T01:10:36+09:00
Subject: Re: Why was the "Symbol is a String"-idea dropped?

On 5/15/07, Robert Dober <robert.dober@gmail.com> wrote:
> On 5/15/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> <lots of interesting stuff snipped>
> >
> > It seems that the HashWithIndifferentAccess class added by Rails in
> > ActiveSupport, which allows symbols and strings to be used
> > interchangeably as keys,

> Is this whole String vs. Symbol idea motivated by Rails stuff?



> I will rephrase OP's question now, why the h[ae]ck did the Core team
> think about unifying Strings and Symbols in the first place ???

I don't know. Probably not motivated, but on the other hand it no
doubt stimulated a reconsideration of the relationship between String
and Symbol.

Whether or not Strings and Symbols have an inheritance relationship is
a bit of an accidental design choice.  Keeping in mind that in a
language like Ruby or Smalltalk, the class hierarchy is really about
implementation factoring and not type specification, as a first
approximation, it doesn't matter that much.  In Smalltalk-80 Symbol is
a subclass of String, but I believe that Symbol overrode the methods
which mutate the instance to cause errors.

But once the decision was made, secondary effects ensue.  If
programmers write code which depends on a particular inheritance
relationship like the case statement in my earlier post, then changes
to the decision will break things.  It's like the story about how
Stewart Feldman decided to use tab as a lexical element in makefiles
and treat them differently from the equivalent whitespace.  He
realized that this was a bad decision, but too late.
From: http://www.faqs.org/docs/artu/ch15s04.html

  "No discussion of make(1) would be complete without an
   acknowledgement that it includes one of the worst design botches
   in the history of Unix. The use of tab characters as a required leader
   for command lines associated with a production means that the
   interpretation of a makefile can change drastically on the basis of
invisible
   differences in whitespace.
 	
        Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't
        tried either, so I figured this would be a good excuse to learn. After
       getting myself snarled up with my first stab at Lex, I just did something
       simple with the pattern newline-tab. It worked, it stayed. And then a
       few weeks later I had a user population of about a dozen, most of them
       friends, and I didn't want to screw up my embedded base. The rest,
       sadly, is history.
	                                             -- Stuart Feldman

Not that I'm saying that Matz's decision on Symbol not being a
subclass of String was a bad one, I'm not, and it's certainly not in
the class of the tab/whitespace 'decision' in make.  What I am saying
is that once made these decisions can quickly generate their own
requirements to exist once a user base has been established.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/