Comments on: Monkeypatching is Destroying Ruby

By: Monkeypatching For Humans | The CyberwBlog

Monkeypatching For Humans | The CyberwBlog — Mon, 14 Jul 2008 11:21:28 +0000

[…] class had subtly different behaviors from the String you’ve learned to use? Monkeypatching can be incredibly dangerous in the wrong hands, as Avdi Grimm notes: Monkey patching is the new black [in the Ruby community]. It’s what […]

By: mdlogix: Ruby on Rails Software Engineer « Toronto Technology Jobs

mdlogix: Ruby on Rails Software Engineer « Toronto Technology Jobs — Thu, 17 Apr 2008 14:28:51 +0000

[…] got some expertise with Rails in-house, including Virtuous Code’s Avdi Grimm (’Monkey-Patching is Destroying Ruby‘). And they’ve just brought on a soon-to-be-ex-colleague of mine, who’s a nice […]

By: darkgoob

darkgoob — Tue, 08 Apr 2008 17:48:31 +0000

There are “programming language communities”? People actually hold affiliation to programming languages?

This is all so very odd. Are there tattoos involved? I bet there are.

You guys should like, have a Ruby sports team of some kind, which would play against the Python team, and all the others of course.

Man, it sounds like people need to take off their Buddy Holly glasses and stop drinking so much damn coffee.

By: Guoping Huang

Guoping Huang — Mon, 07 Apr 2008 12:08:53 +0000

I totally agreed with you on Monkeypatching as a style to code libraries. Patches are just patches. They are not organized codes. However, Monkeypatching does have is values in patching buggy codes and it should stay that way. Combined with the open source nature of Ruby, it is a powerful tool to patch things up the correct way without modifying the 3rd party codes.

We used it in our ShellShadow merb app and it’s working pretty well.See a blog post here.

http://odwks.com/2008/04/monkeypatching-merb/
And yes, it should not be the means for developing libraries(which should uses public api’s).

By: News » Monkeypatching is Destroying Ruby

News » Monkeypatching is Destroying Ruby — Tue, 25 Mar 2008 10:21:11 +0000

[…] Monkeypatching is Destroying Ruby (via). Deliberately provocative title, but makes a well considered case for restrained use of monkey patching in Ruby. Cultural norms around monkey patching seem to me to be one of the core differences between the Ruby and Python communities. […]

By: Geekvicious Journal » Blog Archive » Hands-off my global namespace.

Geekvicious Journal » Blog Archive » Hands-off my global namespace. — Thu, 20 Mar 2008 04:03:46 +0000

[…] Well, after all monkey patching might be destroying ruby. […]

By: andrew

andrew — Mon, 03 Mar 2008 17:29:21 +0000

Nathan: You can use Rails as a black box framework. You can read some tutorials and start programming, use the API docs as needed. But you cannot throw a bunch gems, plugins, generators and engines into your app and expect to be able to debug without an understanding of the code you have written and used. I have worked with .net developers in the past. I present them with a bug and they shrug their shoulders, “that’s part of the framework, i don’t know”. Hoorah for open-source, huzzah for eval, I can change anything because I can read and understand the source ( all of it ), and can modify everything.

By: Nathan

Nathan — Sat, 01 Mar 2008 07:40:13 +0000

@andrew: so you’re saying I can’t take Rails as a black box and simply use it as my web application framework? I have to know the internals as well, just so I can avoid being clobbered by a bad monkeypatch? This is wrong. A framework should support my application, not undermine it. Don’t get me wrong, I like Ruby and I like Rails, but I do not like the monkeypatch-as-programming-model approach that many Rails developers seem to have taken.

By: andrew

andrew — Thu, 28 Feb 2008 18:25:25 +0000

>“monkey patch” is debatable
Ah, there is no such thing as a ruby “monkey patch” or “meta-programming” anyway.

http://dablog.rubypal.com/2007/1/7/meta-shmeta-learning-ruby-horizontally

> less-silly API
true

> self.abstract_class = true
good in theory, not in practice ( if your inheritance is more than one level deep, easier [and more maintainable] to whip out some eval than set this in each subclass )

> community conventions are essential for maintainability
also good in theory, but deadlines kill the virtue and bring out the kludge, i’m still sticking to knowing your code

By: avdi

avdi — Thu, 28 Feb 2008 17:24:09 +0000

@andrew:

> You do monkey-patch in your NullDB. You reopen AR::Base to add a nulldb_connection method.

True. This, unfortunately, is part of the contract of the
ActiveRecord connection adapter API – you are expected to do this if
you want connection_establish :adapter => :foo to work. Whether this
is a true “monkey patch” is debatable; a lot of people only consider
such a thing a monkey patch if it actually redefines existing
methods. Of course, the Rails guys could easily have avoided the
whole question by giving us a less-silly API that allowed us to simply
register a new database connection class.

> Subclassing isn’t always possible. With AR::Base subclasses have special
> semantic meaning, ie. Single Table Inheritance. That is why everything with
> ActiveRecord is done through mix-ins +/or eval. (You can subclass AR::Base
> not for STI but it’s a pain)

It’s not a pain, you just set abstract_class = true.

> Whether it is the Rails framework or a plugin, understand it enough to debug
> it. Then you can eval as much as you like.

This is easy to say, but in real world large projects it simply isn’t
feasible to understand all of the code in the project, let alone all
of the third-party code it depends on. That is why community
conventions are essential for maintainability.

Thanks for the comment!