Michael Schwern gave a two hour talk on refactoring at the Portland Perl Mongers meeting last night. It was a great talk and he finished it with a 19 slide presentation of a step-by-step refactoring of some code posted to a mailing list. All in all, it was a great talk.
One of the interesting things he brought up was the automatic refactoring tools that many languages have. For example, some tools allow you to highlight a section of code and select "make a subroutine out of this". Try, just try, to write a Perl parser that can do that. Oh wait! There is one! It's called PPI and it purports to be a pure Perl parser. From the description by Schwern, it sounds very robust (it parsed MakeMaker, for example). However, the distribution has no docs. Of course, that's not really a problem for a wannabe XP guy. I just need to read the tests.
Oops. No tests.
It looks absolutely fascinating and if it's as powerful as I understood, I want to play with it, but I can't. If anyone has more info, please let me know.
On another note, someone asked at the talk if moving a bunch of stuff into functions would slow the code down as function calls are so expensive. Schwern, to his credit, did not breathe a word about premature optimization. Instead, he pointed out that by refactoring, we can generate cleaner code and start profiling it, thus finding out where the real bottlenecks are. Much better to optimize clean code than spaghetti.
While thinking about the function calls, I started wondering what it would take to have Perl automatically inline function calls when compiling to byte code. chromatic mentioned that he had done some work with this and had some truly elegant code that segfaults quite nicely. Then, Schwern and chromatic started pointing out the problems that scoping causes with trying to inline functions. Further, it's not always obvious what's going to happen when you inline. What happens if you shift something off of @_ and then reuse @_? Or worse, if the code diddles with @_, since it's an alias, I can imagine all sorts of nightmares.
I had briefly thought that I had an original idea, only to discover that others have trod this path before.
Also, I should mention that this is Portland Perl Monger's one-year anniversary of holding regular meetings. Next month, I've invited someone from the local Ruby group to give a brief Ruby tutorial. Much fun!
I'm not sure I said elegant code so much as I said "proof of concept".
Re:Inlining
rafael on 2002-12-12T20:42:01
Proof of concept ? How does it work briefly ? Do you use an attribute:inline or something ? Re:Inlining
chromatic on 2002-12-12T23:13:10
I didn't get quite that far, but that was my plan. It works (er, segfaults) by grabbing the opcodes to the inlinable sub, then splicing them in to the calling sub.
The drawback, as I explained to Ovid, is that the worst overhead appears to be entering and leaving scope, not the actual function call.
Re:Refactoring tools
pdcawley on 2002-12-13T11:32:37
Hmm... time to get CamelBones working properly so I can start spiking out the refactoring tool I'm thinking of. I've done 'extract method' as a proof of concept but oh boy is it ugly. I didn't even have to parse perl...
Catch is, by itself 'extract method' isn't actually that useful... Ah well.
