Re: Monkeypatching is Destroying Ruby

Hi,

I have read all other Statements in this thread, but as it is such a  
vast collection of opinions, its hard to keep track. So: if I mention  
something for the second time, please ignore it ;).

I think the problem with MonkeyPatching is clear: it is a hack and  
hacks tend to die soon. I am strongly opposed to use it in an official  
release without thinking twice. Usually, there is a better way to  
solve the problem. When browsing Rails plugins (i don't want to bash  
rails, but thats an incredibly big source third-party-libraries), I  
often see gruesome hacks to solve problems that could easily be solved  
otherwise - because the author obviously didn't know about the right  
way. Some time ago, many plugins had some implementation of  
String#constantize (better, worse, the same as the Rails version).  
This shows one thing:
Plugin authors are not aware of everything the language has to offer.  
So they do what they do best. Which is not always good. The other side  
of the problem is that the target of your patch is not written to be  
extended (have a look at the "render"-Method in rails) - so you only  
quick resort is a hack.
Monkeypatching is cool - if you think well an at least twice about it.

The problems with meta-programming is another one:
We love it. We advertise it as core features of the language (which -  
in my book - it is not).

Take the above example: Array#to_csv

Why not CSV.from(arg)? It is cumbersome to read and we need to think  
about a way to split the implementation details of from(Array) and  
from(otherType) in halves.  But from an OO-perspective, it makes  
perfect sense: an Array doesn't have to care about the types that it  
can be converted into an it is well encapsulated.

But, because we are lazy, lazy ruby programmers, we love our  
object.send syntax. So we implement a shorthand method. Another  
example is Object.in?(), often seen as a shorthand for  
some_collection.contains?(obj) (Im not sure, but this is called  
'grief', afaik). The first is nicer, the second is cleaner. Many vote  
for the first - another Method in Object. Another well known Library  
defines Object#should because they think of it to be nicer. By doing  
this, we are slowly overloading the core-system. I like approach of  
facets: they are a collection of such idioms, but they must be  
switched on explicitly.
The question you have to answer for yourself when creating such a  
method is: "Is it really that important?". Often I have the impression  
that this question is often answered with "Yeah, its cool and its the  
ruby way!"

On the other hand, those features are the ones that make the little  
difference. Used correctly, open classes are a way to beautiful and  
well constructed code.

It all comes boils to a matter of knowledge, experience and  
discipline. We have got to be aware that many ruby developers don't  
have all of those.

Greetings
Florian Gilcher <Skade>