Re: A new lease on life for Perl Refactoring
On Sun, Sep 16, 2001 at 11:04:48AM -0400, Andrew M. Langmead wrote: > 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". Yes, the two most important things are: Who are the implementors of methods/functions called foo()? Who uses methods/functions called foo()? Everything else is just gravy. > 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. Oooohhh! I had no idea these existed! -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One The drill instructors Have their pots of paste in hand Now the ass games start -- ignatz
ANNOUNCE: Test::Mail 0.03
Now winging its way towards CPAN mirrors worldwide. I've implemented it pretty much as described the other day. Comments etc welcome. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Sure, only 2 percent of the Internet population uses lynx, but they're the top 2 percent." -- petro, on a.s.r
Re: A new lease on life for Perl Refactoring
On Sat, Sep 15, 2001 at 10:45:50AM +0200, Michael G Schwern wrote: > 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? As someone who isn't a huge fan of "GUIs", you might be better working on the module/modules to do it and then we can have different front ends. I like to do all my coding in emacs, an emacs mode for this would be awesome. We could alos have a vi modeand the GUI nonsense for any body who wants that. cheers Andrew
A new lease on life for Perl Refactoring
I'm at, of all places, the Scandinavian conference on Java And Object-Orientation (JAOO). Somebody stumbled upon the How To Be Lazy tutorial and thought I knew something about design methodologies. If nothing else it has the unique advantage of not being in New York. So who do I meet here but Martin Fowler, Mr. Refactoring. I managed to bend his ear for a while on the subject of making a refactoring code browser for Perl, like Smalltalk has. Turns out we're COMPLETELY overthinking the problem. For example. How do you change the name of a class's method and all places that method is called if two classes have method of the same name? ie. You've got Foo::this() and Bar::this() and you want to change Foo::this() to Foo::that() but leave Bar::that() the same. What do you do with: $obj->this Having no idea what class $obj might be of, you have to just eyeball it. So that kills the possiblity of automated Perl refactoring. -->But it doesn't<-- It turns out Smalltalk has the *exact same problem*, and Java does, too. How do they solve it? *They don't*. What they instead do is tell you all the implementors of a given name (so for 'this' it would tell you 'Foo' and 'Bar'). Then you have two choices. 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? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One First day in Prison Back behind the shower door Adhesive applied -- ignatz
Re: A new lease on life for Perl Refactoring
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
Re: A new lease on life for Perl Refactoring
In article <[EMAIL PROTECTED]>, "Andrew M. Langmead" <[EMAIL PROTECTED]> wrote: > 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". Ideally, there'd also be a comprehensive test suite to run after the refactoring to see what breaks. If the browser doesn't catch everything, and if the test suite is kept at 100% pass, and if the coverage is close enough to comprehensive, it ought to catch almost everything else. There's a chapter in Extreme Programming Examined that discusses the Smalltalk refactoring browser. They worked up some sort of change object that can be applied, reverted, and reapplied as necessary. Any change is represented with one of these objects. Granted, that's a ways in the future. The point is, getting an 80% solution, with proper behavior to back it up, is a really really big win. Refactoring without a test suite is a risky business. -- c
