From: Sam Smoot Date: 2008-02-28T23:59:57+09:00 Subject: Re: Proposed Solutions - Was [ Re: Monkeypatching is Destroying Ruby ] On Feb 28, 8:39 am, hemant wrote: > On Tue, Feb 26, 2008 at 11:55 PM, James Britt wrote: > > Trans wrote: > > >  > On Feb 26, 10:45 am, "Jones, Brian - McClatchy Interactive" > >  > wrote: > >  >> I'd be at least a little interested in potentially offering developers > >  >> the chance to 'lock' their classes from monkey patches.  This could be > >  >> useful to the 'core' library that comes with Ruby, and to at least make > >  >> developers look at extension points provided via an actual API instead > >  >> of just immediately jumping on monkey patching for solving all problems. > > >  > That's ridiculous. > > >  Fears about open classes sound very much like what people say about > >  dynamic typing. > > >  "#{@core_feature} is unpredictable!" > > >  "#{@core_feature} creates problems that cannot be found until run-time!" > > >  "#{@core_feature} is unsafe!" > > >  "#{@core_feature} should be locked down!" > > >  It's not that these claims are entirely untrue, it's just that, in real > >  life, most people simply do not encounter the  alleged problems. > > >  Code that is poorly written or does not play well with others tends to > >  get discarded. > > James, Sometime ago Rick Olson wrote this: > > http://weblog.techno-weenie.net/2007/12/19/adventures-in-rails-debugging > > Does ring a bell, doesn't it? All the libraries Rick mentions in his > blog are well regarded and yet he has a problem. > > From my own experience I have encountered similar problems countless > times and you know these problems are HARD to debug. > > As i wrote earlier,  today you have access to source code of all the > libraries you are using because Ruby is source based interpreter and > you can still debug problems because of accidental overrides or > modifying core classes by looking at source code, but what if Rubinius > or IronRuby becomes defacto and people started distributing compiled > bytecodes? > > I propose a small change in the language and perhaps I know it won't > see light of the day, but how about this? > > class Array >   def to_csv #> works if in final program no one is actually doing the same >   end > end > > However, suppose you use another library and they have done the same, > that code won't run and Ruby will throw up and that sorta makes > sense.However, if you are sure of what you are doing, you can go ahead > and write: > > class Array >   def! to_csv #=> similar to override keyword in other languages >   end > end > > Ditto, if you want to override methods defined in other classes, you > must use "def!" . > > I know this is somewhat impractical because Ruby has grown into such a > beast, lots of standard library classes and gems will need small > modification ( but we are in midst of such modification anyways > courtesy of 1.9.x ). > > My point is, I love open classes, but it shouldn't hurt to have little > bit of safety precaution built into the language, does it? I'm with James on this, the wins from Ruby's flexibility far out-weigh the downsides. On the other hand, I don't think I've seen a suggestion quite like this before. It's pretty neat actually I think. Like a poor-man's selector-namespaces. Now if we ever did get selector-namespaces, then I'd be completely against this. But since it appears we're _not_ getting the feature, this isn't a half-bad substitute IMO. Except for the "ruby throwing up" part. Collissions should be warnings, not fatal errors. Otherwise, like you said, you eventually may not have the source for a lib, so you wouldn't have a choice but to abandon it or hack in something like: require 'faster_csv' Array.send(:undefine_method, :to_csv) I'm not saying this def! idea is really needed... but I do thing it's pretty novel an idea, and I don't see any downsides.