From: Dave Thomas <Dave@...>
Date: 2002-11-27T12:03:56+09:00
Subject: Re: Things That Newcomers to Ruby Should Know (11/24/02)

William Djaja Tjokroaminata <billtj@z.glue.umd.edu> writes:

> 1) In my opinion, it is really a consequence of Ruby implementation; for
> people who keeps asking why, probably it is the ultimate answer.
> Ruby will continue to work as now even if all the objects/variables
> are simply implemented as VALUE of type pointer (no "immediate"
> objects).

I believe it's a question of Ruby design, not implementation.

Ruby has reference semantics for all assignment:

    b = a
    c = b

leaves b and c referencing the same object, regardless of that
object's type.

Now, if 'a' happens to be a Fixnum, that would lead to a problem if
Fixnum supported mutators:

   a = 1

   # sometime later

   b = a
   c = b

   b++

   (or b.succ! or whatever)

This would change the object referenced by both 'b' and 'c' (and 'a'),
and hence the value of '1' would be changed.

This already happens with (say) Strings, and every now and then it
causes a surprise (read bug). It happens to me perhaps once every
couple of weeks. Because of this, I'd personally rather have seen
immutable Strings being the default in Ruby (it would also make string
assignment from a constant slightly more efficient).

However, Matz clearly believed that although Strings could be mutable,
having integers whose value changes out from beneath you was a BAD
IDEA. So, he made Fixnums immutable. Having done that, he was then
free to make them value objects.

So, Fixnums (and the rest) are immutable first, value objects
second. The reason they're immutable is not an implementation
decision, but a language design issue.


Dave