On Sat, Sep 15, 2001 at 10:45:50AM +0200, Michael G Schwern wrote: > 1) Change this() to that() in both 'Foo' and 'Bar', and change all > instances of $obj->this to $obj->that. > > 2) Walk through each call to $obj->this and decide if it should > be changed to $obj->that. > > That's it. And the refactoring browser just helps you with the > mechanics of that. > > THAT'S SO EASY! If it works for them, it can work for us. > > > So, I can handle the underlying mechanics no problem. Who's good at > GUIs? >
It seems to me that the main advantage of a refactoring browser in Smalltalk is its proximity to the editing environment. You're coding along, you notice something that seems like one of the "smells" that Beck describes, and so you pull up the refactoring browser. So I'd think the best thing to do to make something that can produce answers to things like "what are the implementors of foo". Then emacs modes, komodo add-ins, and vim macros could be made to read the output and direct the editor. A GUI that displays the results into a bunch of Gtk widgets is pretty simple once we have code that makes the right queries. Tom Christiensens's pmtools http://language.perl.com/misc/pmtools-1.00.tar.gz, might have the start of some of the queries needed for a refactoring system. Things like "pmeth" to tell you what a class implements or plxload to tell you what modules a script uses. To take things from another point, someone once announced on PerlMonks that he was working on a Smalltalk style environment for perl. http://www.perlmonks.com/index.pl?node_id=70415&lastnode_id=864 Maybe a refactoring browser could be added on to that. -- "I'm going to sing Twinkle Twinkle in Jazz: TWINKle, TWINKle, lit-tle-star. HOW i WONder what-you-are..." - Samantha Langmead, age 4
