Re: a modest chainsaw

On Sep 15, 2008, at 17:23, Eric Wilhelm wrote:

> 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

I've used this one many times. I'd like to see it documented without  
the underscore.

> _quote_args()      - just asking for trouble
> have_forkpipe()    - bah
> do_system()        - documented, doesn't do much but juggles PERL5LIB

Which of these are actually used by Module::Build itself?

> 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.

What would replace it?

> 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.

What do you plan to replace these things with?

> 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 see. You'd just put it somewhere else. Do you're not talking about  
cutting down a forrest of methods so much as refactoring it, eh?

> 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.

Yeah…

> 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.

Sounds okay to me.

Best,

David