The Dynamic Def – abusing Ruby's def statement
weblog.jamisbuck.org
The Dynamic Def – abusing Ruby's def statement
1–10 of 87 posts
Re: The Dynamic Def – abusing Ruby's def statement
#2Ha! An IRB-based interactive adventure is actually really, really cool and clever. It never fails to amaze me how much Rubyists abuse metaprogramming and langauge quirks.
Somebody now shall goeth forth and implement Zork...
Re: The Dynamic Def – abusing Ruby's def statement
#3Ha! An IRB-based interactive adventure is actually really, really cool and clever. It never fails to amaze me how much Rubyists abuse metaprogramming and langauge quirks. Somebody now shall goeth forth and implement Zork...
Thanks! I'm not the first to talk about using IRB for interactive fiction, but I think I might be the first to do so using nested defs. :) IRB-based Zork would be awesome! I hope someone does that.
Re: The Dynamic Def – abusing Ruby's def statement
#4Cool article about the craziness of Ruby. Ruby is a frustrating language. The oauth gem, for instance, redefines '==(val)' on the AccessToken to 'Base64.encode(self.signature) == Base64.encode(val).'
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'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's certainly fun to talk about :)
Re: The Dynamic Def – abusing Ruby's def statement
#5Ruby is really fun to program in, but debugging it can be hell. I would not be very enthusiastic about debugging this code.
But still, this is a really cool trick that I didn't know you could pull off with Ruby, so thanks for sharing!
Re: The Dynamic Def – abusing Ruby's def statement
#6Cool article about the craziness of Ruby. Ruby is a frustrating language. The oauth gem, for instance, redefines '==(val)' on the AccessToken to 'Base64.encode(self.signature) == Base64.encode(val).' 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't be using because they break application flow and make it significan…
> The oauth gem, for instance, redefines '==(val)' on the AccessToken to 'Base64.encode(self.signature) == Base64.encode(val).'
Is this just a complaint about the ability to overload operators in general?
Re: The Dynamic Def – abusing Ruby's def statement
#7Cool article about the craziness of Ruby. Ruby is a frustrating language. The oauth gem, for instance, redefines '==(val)' on the AccessToken to 'Base64.encode(self.signature) == Base64.encode(val).' 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't be using because they break application flow and make it significan…
In its place, being able to redefine equality on value types really helps clarify code. Misused, it creates confusion. The problem is that it's easy to think you've got a case where it helps, when actually it's not well-defined. Usually that revolves around there being state you care about which is missed from the equality comparison.
Another trap is redefining #== without also looking at #eql?, which means Hash doesn't behave like you expect. It's just another bit of mental trivia you've got to Just Know...
Re: The Dynamic Def – abusing Ruby's def statement
#8So, about that state machine definition and the method cache...
Re: The Dynamic Def – abusing Ruby's def statement
#9Cool article about the craziness of Ruby. Ruby is a frustrating language. The oauth gem, for instance, redefines '==(val)' on the AccessToken to 'Base64.encode(self.signature) == Base64.encode(val).' 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't be using because they break application flow and make it significan…
In its place, being able to redefine equality on value types really helps clarify code. Misused, it creates confusion. The problem is that it's easy to think you've got a case where it helps, when actually it's not well-defined. Usually that revolves around there being state you care about which is missed from the equality comparison. Another trap is redefining #== without also looking at #eql?, which means Hash does…
Can you give me an example of where redefining equality makes sense?
Re: The Dynamic Def – abusing Ruby's def statement
#10Cool article about the craziness of Ruby. Ruby is a frustrating language. The oauth gem, for instance, redefines '==(val)' on the AccessToken to 'Base64.encode(self.signature) == Base64.encode(val).' 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't be using because they break application flow and make it significan…
> The oauth gem, for instance, redefines '==(val)' on the AccessToken to 'Base64.encode(self.signature) == Base64.encode(val).' Is this just a complaint about the ability to overload operators in general?
It's a complaint about the ability to redefine many things that shouldn't be redefine-able, operators included.