From: dblack@...
Date: 2006-10-16T10:56:27+09:00
Subject: Re: Symbol < String in Ruby > 1.8

Hi --

On Mon, 16 Oct 2006, Yukihiro Matsumoto wrote:

> Hi
>
> In message "Re: Symbol < String in Ruby > 1.8"
>    on Sun, 15 Oct 2006 22:26:11 +0900, dblack@wobblini.net writes:
>
> |I'm wondering if someone could summarize for me the rationale for
> |making Symbol a subclass of String in 1.9.  I understand that symbols
> |and strings both represent text, and have certain characteristics in
> |common, but I always thought of symbols as an internally used data
> |type that Ruby exposes, essentially unchanged, for our use.  It's hard
> |to adjust to thinking of them as string descendants.
>
>  * in preparation M17N enhancement, a symbol should contain encoding
>    information as well as strings.  it was most natural to inherit
>    String class to accomplish this.
>
>  * methods like instance_variables, methods etc. should return
>    Symbols, not mere Strings, because they are exposed internal
>    names.  For better migration path, Symbols should act more like
>    strings.
>
>  * so, Symbols are now immutable, interned strings, with some
>    performance enhancement.
>
>  * Symbol being a subclass of String follows Smalltalk design.
>
>  * as a side effect, option hash tables (like the ones in Rails) work
>    better with strings, without making any hacked hash table.

Thanks for the info!  That's very helpful.

Follow-up question:

Do you expect things like attr_accessor and define_method to take only
symbols in the future?  Or would they still take both?


David

-- 
                   David A. Black | dblack@wobblini.net
Author of "Ruby for Rails"   [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog)        [2] | Co-director, Ruby Central, Inc.   [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com    | [4] http://www.rubycentral.org