Cookie Notice

As far as I know, and as far as I remember, nothing in this page does anything with Cookies.

2010/01/28

Perl Module Design For Dummies, or "I didn't know any better"

I have a 2 KLOC monster. I started writing it and it just grew and grew and grew. Now I hate it, which is sad, because I wrote every [REDACTED] word. Before I started working on it, I hadn't done much with Perl's DBI module and I hadn't written much with modules.

jacoby@oz:~/lib$ ls -l SecGenTools.pm
-rw------- 1 jacoby jacoby 60575 2010-01-26 15:25 SecGenTools.pm
jacoby@oz:~/lib$ wc SecGenTools.pm
2175 8253 60575 SecGenTools.pm
jacoby@oz:~/lib$ grep 'sub ' SecGenTools.pm | wc -l
96
jacoby@oz:~/lib$


Now, I'd love to refactor, break it apart into little pieces, but I'm at a loss about how.

It would be fairly easy to break out SecGenTools::FormTools and SecGenTools::RequestTools and the like. That makes seven kinds of sense. The problem is that I don't have use SecGenTools::FormTools ; in the existing code, I just have use SecGenTools::FormTools ; I could imagine line after line like this.
  1. package Dumb ;  
  2. use strict ;  
  3. use warnings ;  
  4. use Dumb::Dumber ;  
  5. use Exporter qw(import) ;  
  6. our %EXPORT_TAGS = (  
  7.     'all' => [ qw( my_function ) ] ,  
  8.     ) ;  
  9.   
  10. sub dumb_function {  
  11.     return Dumb::Dumber::dumb_function( @_ ) ;  
  12.     }  
  13.   
  14. 1 ;  

But that seems fragile and quite stupid.

Is there any way to seemlessly export the functions of Dumb::Dumber from Dumb without explicitly writing wrapper functions within Dumb? Or am I doomed?

No comments:

Post a Comment