The Dynamic Def – abusing Ruby's def statement

Defining instance-specific behavior of any kind is catastrophic to method caching. JRuby has a hierarchical method cache so it can clear only what&#x27;s needed, but MRI does not:<p><a href="http:&#x2F;&#x2F;jamesgolick.com&#x2F;2013&#x2F;4&#x2F;14&#x2F;mris-method-caches.html" rel="nofollow">http:&#x2F;&#x2F;jamesgolick.com&#x2F;2013&#x2F;4&#x2F;14&#x2F;mris-method-caches.html</a><p>The late, great James Golick had a patch to add one once, but it never got merged upstream.<p>If you care about performance even the tiniest bit at all whatsoever, please don&#x27;t use the techniques discussed in the OP in production code or in your gems. It may make your memos 30% faster on a microbenchmark... while causing the rest of your program to run considerably slower.

Cool article about the craziness of Ruby. Ruby is a frustrating language. The oauth gem, for instance, redefines &#x27;==(val)&#x27; on the AccessToken to &#x27;Base64.encode(self.signature) == Base64.encode(val).&#x27;<p>This stuff feels really dangerous and unnecessary. I spend a lot of time on code reviews pointing out bad features of Ruby (and Rails) that we shouldn&#x27;t be using because they break application flow and make it significantly harder to reason about the code for the small benefit of decreasing a few lines. But it&#x27;s certainly fun to talk about :)

Ruby is really fun to program in, but debugging it can be hell. I would not be very enthusiastic about debugging this code.<p>But still, this is a really cool trick that I didn&#x27;t know you could pull off with Ruby, so thanks for sharing!

Zork-alikes aside... I&#x27;m looking for practical applications :)<p>I recently re-watched Yaron Minsky&#x27;s &quot;Effective ML&quot; talk where (towards the end) he talks about making read-only and read-write types. That&#x27;s where I thought Jamis was going with the state machine example: one could tell an object &quot;yo, make yourself immutable!&quot; (ie redefine your methods so that you can&#x27;t change yourself). But in an OO world that seems more neatly achieved with subclassing. [To the extent of faking anything &quot;immutable&quot; in ruby&quot;].<p>There&#x27;s #freeze I suppose... and no #unfreeze. Which is perhaps sensible :) And #freeze only guards against new assignment to instance variables; it doesn&#x27;t guard against an instance method mutating the content of an instance variable (def esquirify! ; @name &lt;&lt; &#x27; Esq.&#x27; ; end). So there&#x27;s that. But I&#x27;m far from convinced...<p>Python has this &quot;inner-methods&quot; capability (with saner scoping) which is a great antidote for python&#x27;s limited lambdas. But that&#x27;s not a problem with ruby.<p>It&#x27;s a neat trick (and nice to read something from Jamis again). Are there any sensible use cases?

For a much deeper exploration of this kind of dynamic object behaviour in Tcl, Sean Woods&#x27; &quot;Lifecycle Object Generators&quot; is a fun read:<p><a href="http:&#x2F;&#x2F;www.tclcommunityassociation.org&#x2F;wub&#x2F;proceedings&#x2F;Proceedings-2012&#x2F;SeanWoods&#x2F;Lifecycle-of-Objects.pdf" rel="nofollow">http:&#x2F;&#x2F;www.tclcommunityassociation.org&#x2F;wub&#x2F;proceedings&#x2F;Proce...</a>

Ha! An IRB-based interactive adventure is actually <i>really, really</i> cool and clever. It never fails to amaze me how much Rubyists abuse metaprogramming and langauge quirks.<p>Somebody now shall goeth forth and implement Zork...

I&#x27;ve somehow always found Ruby to be opposite to the Unix philosophy of doing one thing and doing it well. While Ruby may seem trivial and fun in the beginning, it tends to be cumbersome and maintainable as the size of the repository grows. Coming from a Python world, my first reaction to Ruby was that it was more like Perl where there are many ways to achieve the same thing, and no it was not really helpful if you inherited poorly written code.

So, about that state machine definition and the method cache...

Just because you CAN do something doesn&#x27;t mean you SHOULD.<p>Metaprogramming has a place in Ruby but for the examples in the article there are far more readable ways to implement it.<p>Readability &gt; cleverness every single time.