Stories
Slash Boxes
Comments
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 ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday December 12, 2002
01:32 PM

Refactoring with Schwern

[ #9420 ]

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!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'm not sure I said elegant code so much as I said "proof of concept". :) Then again, it was pretty hard to hear over the Elvis-impersonator singing the Cure, Nirvana, and Louis Armstrong covers.

    • Proof of concept ? How does it work briefly ? Do you use an attribute :inline or something ?
      • 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.

  • I recently became a convert to IDEA [intellij.com] for Java work. (It's the only thing I've seen that would make me want to give up XEmacs.) Its refactoring is fantastic, and even after a short time it's changed the way I write code similar to unit testing. Testing gives you confidence to make logical changes and thus be more bold about what you try, refactoring tools give you confidence about something like variable/method/class naming. Since it's so easy to change, you can just plow ahead and use the first name that com
    • 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.