Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday August 05, 2008
08:01 AM

"Safe" monkey patching?

[ #37099 ]
The problem: sometimes you need to use a module, but it's broken. There are several really bad strategies for this (I'll explain them after my idea, in case you're curious).

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:

  1. Find and load the HTTP::Request::Common which would have been loaded if this one didn't exit.
  2. Ensure that its version number hasn't changed (in case it's upgraded, you want to see if the "broken" behavior is fixed).
  3. Allow you to then monkey patch it.

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Sounds like a job for maintaining diffs to me. Pull the dists, apply the patches as usual. The bonus is you can overlay lots of other stuff. Or if the module owner is being unresponsive/unco-operative, just fork it and develop it yourself? Or would creating a subclass with your additions work?
  • 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

  • Is subclassing an option?
    • I thought subclassing went out of fashion when the world discovered METAPROGRAMMING! (Alternately, when the world discovered reimplementation and uploading to the CPAN!)