a modest chainsaw

Hi all,

Module::Build::Base is about four times as big as it should be and just 
looking at the quoting bugs makes me want to take a chainsaw to all of 
the following:

 run_perl_script()  - has never been documented
 run_perl_command() - has never been documented
 split_like_shell() - has never been documented
 _backticks()       - starts with an underscore
 _quote_args()      - just asking for trouble
 have_forkpipe()    - bah
 do_system()        - documented, doesn't do much but juggles PERL5LIB


So only do_system() was documented.  My inclination would be to 
deprecate that or at least discourage its use.  And note: the 
documentation doesn't say anything about PERL5LIB.


And while I'm looking around, I also see these and several others which 
should be handled elsewhere or something:

 file_qr()
 ppm_name()
 _files_in()
 delete_filetree()
 rscan_dir()        - documented
 autosplit_file()   - documented

So, I intend to start cutting real soon now.  If anyone has some 
thoughts on how to get away from the single towering inferno of an 
object, I would love to hear them.

And no:  This is not a request for documentation.

I've thought about perhaps a cooperative object arrangement (where the 
helper/plugin/etc passes around a Module::Build - in which case M::B 
hasa helper?) or possibly just the helper hasa Module::Build.

But a lot of these methods are simply wrapping up large chunks of hairy 
cross-platform and historical accident workarounds.  If the method 
doesn't refer to $self, that's a good candidate for exorcism.

I'm starting to think that bundling File::Fu might be a good option - 
then at least I could deal with the cross-platform filename problems in 
one place.

So, if any of these thus-far-undocumented methods are near and dear to 
your subclasses speak now or forever hold the pieces.  The ones with 
questionable APIs will either get a stern warning inserted in their 
guts or could possibly be deprecated altogether.

Of course, the meaning of "deprecated" has to be considered.  Probably 
it means that the method gets pushed off to some other file and 
complains loudly about ever being called, possibly sleeping on the job, 
but never actually goes away.  Of course, that's only necessary where 
it has been documented.

And if the chainsaw sounds too severe, my other inclination is to just 
apply an ::Er to the package names and proceed with the experiment on 
another front.

Thanks,
Eric
-- 
"Everything should be made as simple as possible, but no simpler."
--Albert Einstein
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------