Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
Let's say you want 'DELETE' functionality in HTTP::Request::Common. I'm thinking about writing something like the following:
package HTTP::Request::Common;
use nextlib 1.26;
sub DELETE { _simple_req('DELETE' , @_); }
1;
That would:
Thus, you can monkey patch code, but if the module gets upgraded (and the version number is bumped up), this code could either fail dramatically or maybe just warn very, very loudly.
We have at least 15 modules with local patches and frankly, I'm struggling for a better solution. There have been all sorts of solutions discussed for this problem, but all of them (including mine) suck really, really hard.
Diffs? (Score:1)
You need version ranges (Score:1)
Unless you always have the same version on production and every development machine. Otherwise one machine upgrades, finds the bug is still there, changes the version number, and breaks everyone else.
You should indicate whether versions after the last are fixed, or just not tested. That way you can distinguish between, "I'm continuing to patch this machine that has not been upgraded yet" and "I'm not patching this current machine" and "Check whether this monkeypatch is still needed now!"
Of course once you
Subclass? (Score:2)
Re: (Score:1)
I thought subclassing went out of fashion when the world discovered METAPROGRAMMING! (Alternately, when the world discovered reimplementation and uploading to the CPAN!)