Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pdcawley (485)

  (email not shown publicly)
AOL IM: pdcawley (Add Buddy, Send Message)

Journal of pdcawley (485)

Wednesday January 23, 2002
07:03 AM

Refactoring, again

[ #2344 ]

So, on Monday I was down the pub with Adam and Dave and, as often happens when you're in the company of hackers you haven't seen for a longest time, stuff gets talked about. Dave has already mentioned some of the stuff we talked about in his journal, and now I'm going to talk about something else.

We also got talking about Refactoring; specifically refactoring in Perl, and Adam brought up his theory that if we want Perl co keep on being a popular language, we need to be able to provide the cool tools that people can get elsewhere. Which led to a short riff on cool tools we have admired (DrScheme, which is a kick ass scheme environment, written in scheme (of course) and with some really cool code analysis features; the SmallTalk class browser; eclipse; oobr.el...) for programming in the large.

Programming in the large is what I do (find -name '*.pm' | xargs cat) | wc -l tells me that the project I'm working on at the moment contains 73K lines of code. And it can be really hard to work out what's happening where in such an environment.

I could really use some of the functionality that, say, java programmers using Eclipse take for granted: Intelligent, class tree aware auto completion; useful and useable class browsers that let you jump straight to the method's definition, or to its superclass, or wherever.

I also want more advanced magic. A refactoring engine that will let me select a bunch of code from within an existing method and turn it into a seperate method, prompting me for method arguments and return values; that lets me rename a method, and goes through the sourcecode showing me the places where that method is called from and asks if I want to change those too; something that lets me change the name of a variable, reliably, with no false positives.

I'm currently working on the 'advanced magic', I have a refactoring engine that can turn a selected piece of code into a method call, and which automatically writes the method too. It's not yet desperately reliable. It's not proveable in any sense and I need to add pre and post conditions to help me guard against bad cases, but for a rigged demo it's pretty damned impressive, though I say so myself as shouldn't.

And it dawned on us on Monday night that the tools and techniques I'm developing to get this deep magic to happen will be remarkably useful for doing the 'easier' stuff too. In fact, I have the horrible feeling that in order to get the refactoring engine to 'work' I'm going to have to write an entire IDE. Unless someone can show me how to get EPL, the emacs perl lingo working reliably.

So, I'm inspired again and busily trying to get my head 'round the internals of the perl debugger, the B::* modules and all that other deep voodoo that lets us inspect the state of our modules.

Who knows, I may even release something to CPAN soonish.

Or maybe I'll tidy up Acme's::Abbreviations first, it needs some tests. And documentation...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.