As for my “real experience”, I wrote the accessor refactoring over 22
years ago. Since then, I’ve had several times that it has saved me from
overriding a method that I didn’t want to be overridden. As for saving
me from destroying the system, it most likely has, but not in the way
you probably expect. When I would test the refactorings, I would
purposely try to destroy the system by doing dangerous things. If the
system crashed, I would fix the refactorings, or add an explanation that
the refactoring didn’t/couldn’t check for that behavior. Testing in this
way gave us confidence when giving demos. We could allow people to yell
out refactorings that they wanted to see performed and we were fairly
confident that everything would keep running. Over the years, we renamed
Object to Thing, True/False to False/True,
I would love to try these three ;)
#+ to #p:, extracted/inlined
bunches of code in String and OrderedCollection, etc. Only once in all
of the demos did we destroy the system. We renamed a method that was
being used by the process scheduler. We don’t try to fix running code
with the new names so when the original method was removed, the process
scheduler threw an error and crashed the image.
This is a cool example.
Pablo is working on updating instances during a refactoring and we should
try.
We could have had the
rename method refactoring handle this case also, but that would have
required some non-portable code.
John Brant
--
Using Opera's mail client: http://www.opera.com/mail/
