----- Original Message -----
From: "Bill Spight" <bspight at pacbell.net>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, February 15, 2003 10:07 AM
Subject: Re: Mutable Points/Rects in Morphic

> Hmmm. What about creating a MutableRectangle subclass? Not that you
> haven't thought of that, but why not? It would be available for those
> Morphs that need it, and would not bother those that do not use it. (I
> don't know other alterations would be required to make that option
> available.)

I put some effort into seeing how well this would work.

The main thing that would benefit is Morph's bounds and fullBounds
variables, which get updated very frequently.

The tricky thing is that code needs to know whether its dealing with the
mutable versions or not. Much of the current code breaks when the
assumptions of immutability are broken. (And when it breaks, the UI is
usually hosed, so it takes a while to track down whats going on.). For
example, morphs access bounds directly all the time in ways that are unsafe
with mutable rectangles. It could be made safe if they all used the bounds
accessor method. But then we'd have to make a copy for each access, which is
probably worse than the current situation.

In an ideal world, I suppose we'd use the mutable bound/fullBounds in
Morph's private methods. Morph would give out a safe copy for use external
to the class. But at this point, the implications of messing with this look
too deep.

Maybe after the morphic cleaning project has had some time to work it could
happen. It would be nice, because morphic could probably get 10%-20% more
speed overall. In addition to the much reduced garbage load, mutable
versions of Rectangle/Point can do their operations around twice as fast as
the current ones, and these operations are used very heavily in morphic.

Eddie