[ruby-talk:21720] Re: manipulating "immutable" objects such as Fixnum from within callbacks & al...

On Wed, 26 Sep 2001, Joel VanderWerf wrote:

> It's more than an implementation trick--it's a desirable feature.
> Programmers expect numbers to have copy semantics, not reference semantics,
> regardless of their internal representation. That's why, even though floats
> are internally stored as references, the following is correct:
>
> x = 1.0
> y = x
> y += 1
> p y
>   ==> 2.0
> p x
>   ==> 1.0

What if we made x and y be references?

x = IntegerHolder.new(1.0)
y = x
y += 1 # this is the same as y = y + 1
puts y    #=> 2.0
puts x    #=> 1.0
p y       #=> #<IntegerHolder:0x4027b8b0 @integer=2.0>
p x       #=> #<IntegerHolder:0x4027bbe4 @integer=1.0>

Here you can see a builtin class behaving just the same as an Integer.
How would this work?  Well, the + operator, generally speaking, returns a
new object:

class IntegerHolder
  def initialize(integer)
    @integer = integer
  end
  def +(other)
    case other
    when IntegerHolder
      return type.new(@integer + other.integer)
    else
      return type.new(@integer + other)
    end
  end
  def to_s
    return @integer.to_s
  end
end

The reason this is possible in Ruby is because (with the exception of <<)
operators in Ruby do not modify the original object.  (Of course, this
depends completely on the implementation of the class in question, but
genreally speaking, it's a bad idea to overload an operator in a
particular class to have different semantics as that operator in all the
other classes out there).

The "implementation trick" that Guillaume mentioned is in that integers in
Ruby really are immediate values, rather than "references to ints" as some
people like to think about them.  From the Ruby perspective, they
certainly look like "references to ints", but this is just a disguise for
the hack.

Paul