Re: Symbol < String in Ruby > 1.8

Java does this also.  The String class is immutable.
Java marks the class as final which means that users cannot subclass it.
This is necessary to prevent users from modifying the string after it 
has been created.
Java does this so that the VM can hash the string and take shortcuts to 
improve string performance.
Any string method that modifies a string in Java returns a new string 
object.

Downside:
This can create a large quantity of "dead" string objects that have to 
be garbage collected.
String concatenation becomes an expensive operation (copy required) that 
can not always be optimized away.
Hence in java the StringBuffer class appears which is really a buffer, 
not a string.

Upside:
Every string is a "symbol"
The VM can optimize string compares and reduce memory usage.

Kevin Tew


Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: Symbol < String in Ruby > 1.8"
>     on Thu, 19 Oct 2006 14:08:07 +0900, Sam Roberts <[e-mail]> writes:
>
> |Been working with lua recently (lua.org), it only has immutable strings,
> |so all strings are effectively interned at creation, comparison between
> |them is "cheap" after that, and memory is collapsed because there is
> |never more than one instance of the same string.
>
> Interesting.  All strings?  Is the result of string substitution, for
> example, also interned?
>
> |One nice thing about having two kinds of string related by a mixin
> |instead of inheritance, like InternedString/Symbol and String both
> |mixing in Textual rather than String inheriting from InternedString, is
> |that the mixin may be usable by other classes that also want to be
> |duck-typeable as strings, but don't want to implement all the many, many
> |methods of String. It might be hard to figure out the right breakdown
> |between class and Textual mixin, but it sure would be nice.
>
> Module can not rely on the internal structure of object, so that all
> methods defined in the module (Textual?) should be based on some
> primitive methods.  For example, methods in Enumerable are based on
> #each (and several others).  I am not sure we can define such
> primitives for Textual methods, without hindering the performance.
>
> Besides that, making two independent classes, String and Symbol (or
> InternedString or whatever) is rather trivial.  I can do it in 10
> minutes or so.  The point is the rationale, and trade-off.
>
> 							matz.
>
>