Is there a tool here, begging to be written? Why can't I point to a Ruby object and ask it "Hey, where did that method come from? Which file/method/object defined that? Which were the last three files/methods/objects to redefine that?"
Obviously, you wouldn't want to enable this feature on a production server. But it might be a useful debugging tool. Worth a try, anyway.
Such a thing would only help in tracking down problems. It wouldn't resolve the larger problems of, e.g., namespace collision. ("Oops, library foo and library bar both tried to define an Object.stupify() method!"), though it might make such issues easier to detect. And it would be quite easy to write perverse programs that would defeat my proposed debugger thingy, or even cause it to melt. ("My program uses singletons to dynamically redefine methods on other singletons.") But you could perhaps mitigate the latter by restricting this tool to monitoring Ruby's built in classes, and/or whatever classes the user specifically chooses to aim it at. Moreover, if a piece of Ruby code did cause the metaprogramming-tracker to dump core, that fact might serve as a valuable code smell of its own.
Heh. Oddly, the solution to convoluted monkeypatching might be monkeypatching itself. Any reason why you couldn't extend the Object class to have this self-knowledge? Or couldn't a library be required at program start that works like Perl's 'use strict;', keeping you on the straight and narrow and not falling into the tempting trap of extending classes when you shouldn't be?
the solution to convoluted monkeypatching might be monkeypatching itself
Yes, the very same thought occurred to me. Set a monkey to catch a monkey!
I didn't suggest it myself, because I've been away from Ruby just long enough that I didn't remember whether one could accomplish this in pure Ruby, or if one would have to ascend up a level and do it in the interpreter.
yeah, it's possible in pure ruby. You can do stuff to prevent monkey patching, as well as do stuff to make it easier for future monkey patchers. I prefer libraries to not do either, to make code easier to use.
Comments
Is there a tool here, begging to be written? Why can't I point to a Ruby object and ask it "Hey, where did that method come from? Which file/method/object defined that? Which were the last three files/methods/objects to redefine that?"
Obviously, you wouldn't want to enable this feature on a production server. But it might be a useful debugging tool. Worth a try, anyway.
Such a thing would only help in tracking down problems. It wouldn't resolve the larger problems of, e.g., namespace collision. ("Oops, library foo and library bar both tried to define an Object.stupify() method!"), though it might make such issues easier to detect. And it would be quite easy to write perverse programs that would defeat my proposed debugger thingy, or even cause it to melt. ("My program uses singletons to dynamically redefine methods on other singletons.") But you could perhaps mitigate the latter by restricting this tool to monitoring Ruby's built in classes, and/or whatever classes the user specifically chooses to aim it at. Moreover, if a piece of Ruby code did cause the metaprogramming-tracker to dump core, that fact might serve as a valuable code smell of its own.
Heh. Oddly, the solution to convoluted monkeypatching might be monkeypatching itself. Any reason why you couldn't extend the Object class to have this self-knowledge? Or couldn't a library be required at program start that works like Perl's 'use strict;', keeping you on the straight and narrow and not falling into the tempting trap of extending classes when you shouldn't be?
the solution to convoluted monkeypatching might be monkeypatching itself
Yes, the very same thought occurred to me. Set a monkey to catch a monkey!
I didn't suggest it myself, because I've been away from Ruby just long enough that I didn't remember whether one could accomplish this in pure Ruby, or if one would have to ascend up a level and do it in the interpreter.
yeah, it's possible in pure ruby. You can do stuff to prevent monkey patching, as well as do stuff to make it easier for future monkey patchers. I prefer libraries to not do either, to make code easier to use.