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
