3 ms·

I think I've only ever used it once, and that was in a place where refactoring my way around needing to know that was more trouble than it was worth at that poi

I think I've only ever used it once, and that was in a place where refactoring my way around needing to know that was more trouble than it was worth at that point. I label it as evil, because people I've shown it to range from "that's amazing, I'd never allow it in production code" to flat out "that can't work". So it's not a common idiom in my experience, nor do people usually grok it on first pass so to me it fails "write unsurprising code" as someone who is part of a team. Each to their own of course, the "evil" positioning of the post was a bit of sarcasm to me really. I would use those techniques in situations appropriate to them. For the most part, I'll avoid them though, especially in code that I know won't be a simple one-off script.

Xylakant 14y ago
I agree that this trick is a bit hard to really understand if you first see it the first time and even harder to come up with, but I think it's quite readable even if you don't understand what exactly is going on under the hood. So I'd have no qualms about using or allowing it in production code. It's safer than any proposed alternative, readable and does the job. Whether it's actually good architecture to depend on that knowledge is another discussion, but there's cases where it's required (see the inject example in this thread) I'd never allow the instance_eval trick though, because that obfuscates the code for sake of saving a local variable.