From: Brian Candler <B.Candler@...>
Date: 2007-05-15T16:30:16+09:00
Subject: Re: Why was the "Symbol is a String"-idea dropped?

On Tue, May 15, 2007 at 10:07:24AM +0900, enduro wrote:
> It is tempting to say: "Symbols are just integers internally,
> they are just isolated points in 'Symbol-space',
> so it is not suitable to give them string methods."
> But I think in practice this is not true:
> - Symbols are a standard data type for meta-programming
>  (and immediately, there will be a need to append a "?" here and then,
>  or test for some regexp-condition...)
> - Symbols are fast as Hash keys,
>  but the "real-world" keys often are strings, or even can be both,
>  and then the current situation creates the well-known dilemma
>  to decide for a Symbol/String interface (and implement it).

The programs for which it makes sense to convert strings (received from some
external source, e.g. a database) to symbols for optimisation purposes, i.e.
where the benefits are measurable, will be pretty few. And you also open
yourself to a symbol exhaustion denial-of-service.

That is, as far as I know, the symbol table is never garbage collected. Once
a symbol, always a symbol.

So using literal symbols as hash keys makes sense:

  { :foo=>1, :bar=>2 }

but using

  h = {}
  h[a.to_sym] => 1

is risky, and unlikely to yield measurable benefit. If 'a' is already a
String, then there is no benefit from avoiding object creation, since it's
been already done. So you may as well leave it as a String.

> Yes, I sometimes think of that separation of Symbol from String
> as a tiny impurity in the Ruby crystal.

I would disagree with you there, because Symbols are clean and easy to
understand.

There are other "impurities" I can think of - like the seven or so different
flavours of Proc object which have subtle different semantics. This I find
more difficult, because it's really hard to remember the rules for how they
differ. But things like this are here to make the language "do the right
thing" in most practical cases. And, once you've used Ruby for a while, you
find that actually it does.

> I thought Ruby 2.0 could have been a chance to iron this out.
> But it seems that now only small changes are still possible.

I'd vote strongly against anyway. I *like* Symbols as they are. I also don't
feel a dichotomy. Use a symbol where necessary (i.e. for method names) and
for literal hash keys, e.g. named arguments. For anything else a string is
just fine.

I agree it's a bit annoying when you come across a bit of code which
violates the standard practice: e.g. net/telnet uses
    { "Prompt" => /foo/ }
instead of
    { :prompt => /foo/ }

But then even :Prompt would have been annoying, because generally people
don't use the capitalisation either.

Do you think that hash['a'] and hash['A'] should be the same?

Regards,

Brian.