Re^2: Upgrade-proofing overridden subroutines

If you need to change the code, patching it directly is the wrong thing to do. What happens if I don't override and instead patch? Many (probably most) programmers work for companies where testing is simply not done. I can say "just run your tests", but the reality is, I want to make things workable for people regardless of whether or not they run tests. There are also companies which have learned the value of testing but still have plenty of code which doesn't yet have tests. Again, the strategy of an external patch which breaks when it needs to is safer than a silent failure on upgrade. Also, I know plenty of people who couldn't patch XS code if it's the XS which is buggy.

As for waiting for a patch to be applied, that becomes problematic when working with code that hundreds of people use, many system administrators might or might notice and a bundle of programmers could possibly rely on. If I wait over a year for a patch but everyone who knows about this has left in the interim, having code mysteriously break on upgrade is far worse than having it clearly designed to break due to an external patch. I agree that Sub::Override is not an optimal solution, but I'm not always able to control when a module is going to get updated and in large companies, sometimes you need a better failsafe mechanism.

Cheers,
Ovid

New address of my CGI Course.

Comment on Re^2: Upgrade-proofing overridden subroutines

Replies are listed 'Best First'.
Re^3: Upgrade-proofing overridden subroutines by perrin (Chancellor) on Aug 15, 2006 at 16:47 UTC
I thought you were talking about your specific case, where I assumed you will have tests. We package our installs with specific CPAN sources, so we never risk accidentally upgrading something. When we patch something, it's essentially the same as what you're doing -- an in-house change that works with one known version. The in-house code is marked with a different dist name than the CPAN dist. It would take a willful act to replace it with a different version.	[reply]
Re^3: Upgrade-proofing overridden subroutines by polettix (Vicar) on Aug 17, 2006 at 15:25 UTC
If this is the case, your runtime overriding solution seems a bit fragile. In this case, if the original author/authors are unresponsive, the best you can do is to fork off from their work and use your forked modules in the code you deliver. You could pack the patched modules in your work, or give something to the community releasing the patched module (this is up to you and to your willness to cope with bug fixes in your forked module). Yes, we all know what forking means, but you're probably thinking about forks in really active projects, where at a certain point different people would like to go in different directions. This does not seem the case of almost-dead modules IMHO. If the original author(s?) come back to life, then, you can either decide to put your code back to their modules in your next release, or just stick to your already-working code. This probably depends on how much confidence you give to their rebirth, or how many bugs were solved in their patched version. But, again, you keep control over what you deliver, and don't get catched by accidental changes. Last, but not least, you don't get blamed if your Sub::Override doesn't work for that nasty corner case you didn't think of. Flavio perl -ple'$_=reverse' <<<ti.xittelop@oivalf Don't fool yourself.	[reply]