https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112015-12-30T00:41:38ZRuby Issue Tracking SystemRuby master - Feature #11911: Immutable method definitions and/or static dispatchhttps://bugs.ruby-lang.org/issues/11911?journal_id=558572015-12-30T00:41:38Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Feedback</i></li></ul><p>Ruby's ability to change any method anytime, and C++/Java's ability to overwrite some methods in subclasses, are conceptionally quite different. Which one are you interested in, and why? What is your use case?</p> Ruby master - Feature #11911: Immutable method definitions and/or static dispatchhttps://bugs.ruby-lang.org/issues/11911?journal_id=559302016-01-03T07:04:56Zmlarraz (Matt Larraz)
<ul></ul><p>I suppose I'm talking specifically about the first, that is, the ability to change any method at any time.</p>
<p>The most obvious use case I can imagine is an application that wants to guarantee that it's running the stock stdlib, with no monkey patches. Given a large enough number of gems (or even files in the codebase itself), auditing all of them for monkey patches becomes expensive. <em>Consistently</em> auditing all of them to ensure no monkey patches get introduced becomes cost-prohibitive. In such a case, it might also be convenient to have a command-line flag that disables any modifications to the stdlib.</p>
<p>As a highly contrived example, a malicious gem author could hide a monkey patch in the middle of his codebase, overwriting <code>Kernel#puts</code> to spy on all of the application's output. There is presumably a non-negligible number of Ruby developers who would like to easily guard against something like this.</p>