On Tue, Feb 9, 2010 at 12:54 AM, George Sakkis <span dir="ltr"><<a href="mailto:george.sakkis@gmail.com">george.sakkis@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

So I'm wondering if there is a consensus on when it's better to (hard)<br>
patch, monkey patch or just try to work around a third party package<br>
that doesn't do exactly what one would like. Does it have mainly to do<br>
with the reason for the patch (e.g. fixing a bug, modifying behavior,<br>
adding missing feature), the given package (size, complexity,<br>
maturity, developer responsiveness), something else or there are no<br>
general rules and one should decide on a case-by-case basis ?<br></blockquote><div><br></div><div>IMHO, monkey-patching is one of those things that you shouldn't really mention in the public without looking both ways, leaning in, and lowering your voice.</div>

<div><br></div><div>Its not that its -bad- exactly, and its really not terribly kinky or obscene, but its something that you still shouldn't exactly do in polite company, y'know?</div><div><br></div><div>There's no guarantees it'll work forever, so its not the safest practice, but if you're willing to accept the burden (and ideally have a unit test proving that it still functions after an update to such a package), then... consenting adults! Go ahead.</div>

<div> </div><div>If you can get the upstream package to make such a thing not necessary, that's ideal-er, of course.</div></div><br clear="all"><div name="mailplane_signature">--S</div>