From: Ryan Leavengood <leavengood@...>
Date: 2005-12-23T07:16:47+09:00
Subject: Re: Diff of opinion on dynamic stuff

On 12/22/05, Drew Mills <drewmills@gmail.com> wrote:
> Let me preface this post by saying that I'm no Ruby expert.  I like it.
>  It's fun.  But I won't claim extensive knowledge on it.
>
> So when this guy blogs about a Python quality that he feel is better
> than a Ruby quality:
>
>     It's the second generation that's going to be less enthused,
>     that's going to stare in bafflement at these classes that
>     mysteriously spawn methods, and trying to figure out what's
>     going when there's an exception in dynamically generated
>     code. You can monkeypatch code in Python pretty easily, but we
>     look down on it enough that we call it "monkeypatching". In
>     Ruby they call it "opening a class" and think it's a cool
>     feature. I will assert: we are right, they are wrong.
>
>     -- http://blog.ianbicking.org/theres-so-much-more-than-rails.html
>
> I am curious what this means.  Is Python against dynamic stuff?  And
> Ruby for it?  And so we just agree to disagree?  Or do I misunderstand?

I think what he is complaining about are some of the dynamically
created convenience methods provided by ActiveRecord when dealing with
the Model for a database. Things like Person.find_by_user_name are
methods which are implemented using method_missing to do specific
searches of database tables. Because these aren't "real methods", Ian
feels they could be hard to debug. He probably has a point. But in
this case I think the convenience overrides the occasional weird bug.
I don't keep up with the Rails list and haven't done much Rails
programming yet, but it might be interesting to see how many problems
there are related to these kind of methods. I suspect in reality there
are many less than what Mr. Bicking might think.

Also his lack of Ruby knowledge is showing in that he is talking about
method_missing implementations being like "opening a class", which
they aren't. They are basically dynamic method dispatch.

There are a lot of neat things that can be done with method_missing
that are very powerful and convenient. I certainly do not subscribe
the Pythonic "it is better not to have something powerful if it can be
occasionally dangerous" philosophy that Mr. Bicking is describing. I
suspect most other Rubyists (and Matz) have the same opinion.

Regarding the issue of "re-opening a class", there is certainly room
for abuse here. Again in my opinion the convenience and flexibility
this provides probably out-weigh the risks. Others may not agree. But
there are a lot of major Ruby libraries that would be totally
different and/or impossible if we didn't have this feature. Rails and
RubyGems both come to mind, as well as a lot of the code provided in
the standard library. All I know is that I really cringe when I look
back at Java code which requires separate utility classes for special
String methods instead of just adding them to the String class (which
you cannot do in Java without the source code for it.) To me it makes
sense to just re-open the class and add the methods there, where they
belong. But I've been programming Ruby for quite a while, so maybe I'm
just brainwashed ;)

Ryan