From: Eric Mahurin <eric.mahurin@...>
Date: 2007-09-07T12:14:02+09:00
Subject: Re: Twisting a Rope (#137)

On 9/5/07, Eugene Kalenkovich <rubify@softover.com> wrote:
> "Eugene Kalenkovich" <rubify@softover.com> wrote in message
> news:JkJDi.3699$tY2.57@trndny01...
> > "Eric Mahurin" <eric.mahurin@gmail.com> wrote in message >
> >
> >> I added dups to Kalenkovich's code and saw the same 150+MB usage as
> >> Munkby's dup code.  I still don't understand this.
> >
> > I'm not sure about Gustav's code, but for my one memory in duping option
> > is eaten by normalization, that do not really need any duping at all.
> >
> > --EK
>
> I've modified my code to avoid duping in normalization - at a cost of
> ugliness :) (too ugly for quiz submission, and anyway, too late :)

Here is another issue that is akin to the self-assignment problem in C++:

r1 = Rope.new("A")
r2 = Rope.new("B")
r1<<r2
puts r1
r1<<r1
puts r1

When you are modifying self and an operand for that modification can
be self, you have to be careful about the order in which you do
things.  I imagine some of the other implementations have this
problem.

BTW, I sped up my code by another 20% by simply using
attr_reader(:left,:right,:length,:depth) instead of defining the
methods explicitly.  I always thought these attr* things were just a
convenient way to define getter and setter methods.  Now, I'll be
using them more since there is a significant run-time benefit.