Chris's Wiki :: blog/python/MonkeyPatchingLimitation Commentshttps://utcc.utoronto.ca/~cks/space/blog/python/MonkeyPatchingLimitation?atomcommentsDWiki2012-11-25T15:32:40ZRecent comments in Chris's Wiki :: blog/python/MonkeyPatchingLimitation.From 87.79.236.202 on /blog/python/MonkeyPatchingLimitationtag:CSpace:blog/python/MonkeyPatchingLimitation:e2f0ded3571dd0a5374abd9679fd012fbc088fc4From 87.79.236.202<div class="wikitext"><p>The question of what happens if a class becomes non-monkey-patchable probably has no significance as a disincentive. Evidence that points to this is… the very fact that people do monkey-patch core Ruby class. After all, a class becoming non-monkey-patchable is not the only way that a monkey patch against it may break, and is arguably not even the most plausible way. Far more likely is that the class would get extended in ways that conflict with your monkey patch. Yet the Rails community had to find this out the hard way. So if they paid no mind nor heed to this potential, then the fact that a class may turn non-monkey-patchable outright is probably no deterrent either.</p>
<p>The fact that there are many classes that <em>cannot</em> be monkey-patched <em>right now</em>, however, would certainly act to set a (probably strong) cultural precedent, in a Sapir-Whorf kind of way.</p>
<p>—<a href="http://plasmasturm.org/">Aristotle Pagaltzis</a></p>
</div>2012-11-25T15:32:40Z