# from Eric Wilhelm
# on Sunday 08 October 2006 05:17 pm:
>>ATM, I've just written this into our build
>>subclass, but would be happy to make it a patch if there's interest.
>
>ping.
2 packets transmitted, 0 received, 100% packet loss, time 259200s
And here I was just thinking how beautifully this feature fits into the
precedent of the recently added 'testpod' and 'testpodcoverage', not to
mention 'testcover', plus how easy it makes it to override the default
behaviors of those, and I guess I could also say something about how it
might help stifle further "test*" feature creep.
So, what should I do? Just keep growing my own custom build subclasses
until I basically end up with my own Module::Install problem of having
to update the bundled installer in 20 distributions? Or, release
Module::Build2 or something? (Not that I'm out to make a hostile fork,
just that I have written some functionality and would like it to get
upstream.) Subclassing gets ugly when you have to copy all of the
original functionality to get finer-grained code reuse. I've tried
submitting patches before, but when they get ignored or refused I end
up having to revert my svk tree to keep up with the trunk. Given the
nature of this proposal, I thought it would be fair to request feedback
on the workings or usefullness before I go code-up tests and make
patches.
I'm not writing this to complain (and hopefully it isn't taken that
way.) I just don't know what to do when I can't get positive or
negative feedback on a proposal. If this is a stupid idea, please tell
me why.
Thanks,
Eric
--
"Insert random misquote here"
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
