I think this would be easier to do if they would improve Ruby's syntax to have all expressions be enclosed in 2 delimiter characters of some kind (the first would signify the beginning of an expression and the second would close it). Expressions can of course be nested. For calling functions, the first element in the set would be the symbol the function is bound to, and the other elements would be its arguments. This way functions and data would have the same notation. These simple changes to Ruby's syntax would make rewriting or generating expressions, whether at compile time or during run time, much more graceful.
Rewrite, for people who are more comfortable having their code parsed to an AST, modified, and recompiled, by a third party library, than they are with making sure they don't pick stupid method names for Object extensions.
I think some of the suggestions around namespacing methods would also help, and would help in a very clean fashion. But as long as extending core classes happens in a single global namespace, there are going to be problems.
Although it wasn't mentioned in this particular post, the problem is acute for people using extensions for their own third-party libraries. If you install gem foo, and it uses something with "stupid method names for Object extensions," your code is now infected with stupid method names for Object extensions.
What happens if you use gems foo and bar and they conflict with each other? Even though you went out of your way to eschew Object extensions, the authors of gems foo and bar may not have been so hygienic.
My hope is that some mechanism for avoiding this problem becomes popular. This may not be it, but crossing yourself and hoping nobody else uses your method names or conflicts with each other does not scale very well.
Part of the problem is Ruby's hackish module system. When you include a module, you are taking everything, whether you like it or not.
I have created a library to help manage includes, and make them more like imports in other languages that have real modules. (You can selectively include methods from a module)
http://github.com/gregwebs/module-import/
I totally don't see how this is a win. The monkeypatch problem is that multiple people are competing for the same names on Fixnum, String, Array, Hash, and Object. To solve that problem, your code would need to allow a Fixnum to support Numeric#to_asn1 in my code, but pretend not to have it everywhere else.
This is not a solution to the problem, but it picks away at it. The goal of this is to prevent unnecessary namespace pollution. So if in your code you say
class Object
import MethodChain, :tap
end
You will never import MethodChain#chain or any other methods into Object, and you will never have to worry about re-writing those methods.
If you're careful and you're not extending Fixnum, you can use Object#extend to keep your monkeypatching constrained.
I'm a bit skeptical about the severity of this problem, though. It's the same problem faced by C programmers for the past 30 years, and it hasn't really retarded library development. If anything, the Ruby problem is far simpler, since you can choose one of many different namespaces to add your global symbols to.
Well, considering that I wrote the andand gem that actually does extend the Object class, it should be clear that I am comfortable with the idea of selectively extending core classes.
However, I am also keenly aware that there are others with different viewpoints. For example, andand was first used in production on an application with a handful of developers and a medium-sized collection of classes.
I have done some work with another application that has dozens of developers in multiple locations and considerably more classes, almost an order of magnitude more. The developers on the second application are far more conservative about extending core classes.
I am also very sensitive to the downstream client problem. When working on your own project, you can do whatever you want. But when writing a gem or plug-in for others to use, you need to be much more conservative about introducing extensions, because they get them whether they want them or not.
For that reason, the rewrite gem doesn't use andand.
