Yukihiro Matsumoto wrote:
>   * 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.

My understanding of symbols was primarily that they were an ID within 
the runtime that happened to have a convenient string form, rather than 
a string that was used as an ID. Is this an incorrect way of thinking?

> 
>   * 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.
> 

This seems reasonable, for both 1.9 and 1.8, actually.

>   * so, Symbols are now immutable, interned strings, with some
>     performance enhancement.
> 

This seems to raise a red flag for me. String, the superclass, will be 
mutable, and has mutating methods on it like << and reverse!. Now Symbol 
will be a subclass of String, but it will not fulfill several of 
String's promises. Symbol will be kind_of? String, but you can't << or 
reverse! it. Moreover, this seems to be anti-OO...the contract of the 
superclass is not being maintained by the subclass. By asserting that 
Symbol is immutable, you are automatically saying it is not String, 
since all Strings are mutable.

The remaining reasons seem logical enough, but this issue really bothers me.

-- 
Charles Oliver Nutter, JRuby Core Developer
headius / headius.com -- charles.o.nutter / sun.com
Blogging at headius.blogspot.com