From: "David A. Black" Date: 2008-12-05T07:53:47+09:00 Subject: [ruby-core:20333] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly) Hi -- On Fri, 5 Dec 2008, Charles Oliver Nutter wrote: > Dave Thomas wrote: >> Please, no. >> >> Every time we do something like this, we add more special cases to the >> language. Right now, classes are open. We allow people to modify their >> behavior. That's just Ruby. Take away plus, and you limit my freedom. >> What's next? Maybe Fixnum.to_s. And then maybe Struct.to_s. And then maybe >> all internal classes get closed, and no one would be able to create things >> such as Symbol.to_proc. >> >> I'd much rather see change going the other way. I'd like to see a = "cat" >> calling String.new. I'd like to see fewer special cases. >> >> If require is broken, then fix it. But don't stop me replacing it if I >> want. And if I replace it incorrectly (making it not thread safe, for >> instance) that then becomes my fault. >> >> Ruby is about choice. If I wanted a language implementor to tell me what I >> can change and what I can't change, I'd use Python or Java. > > I can appreciate the "choice is good" argument, but I think the Ruby world > needs a little less dogmatism about "choice" and "freedom" and "beauty". > There's practical concerns here, concerns about API stability, thread-safety, > performance, memory efficiency. Too many of those concerns are sacrificed on > the altar of "choice" or "freedom". > > In the case of core classes, we're not talking about closing them down > completely; we're talking about guaranteeing to all developers and users that > some minimum set of methods will do what you expect them to do, now and > forever. We're guaranteeing that 1 + 1 will continue to == 2. And it's not > the case where *you* want to override a core method that's the problem...it's > the case where someone else overrides it--potentially by mistake--and you > don't find out about it until later. > > Ruby needs to grow up as a language by allowing people who want guarantees to > get guarantees. And there's a lot of people who want some minimal, basic > guarantees about core classes. It's not a growing-up thing, though. The freedom of Ruby isn't the freedom of an undisciplined or pre-socialized child; it's an informed, elective, adult state. For me, this particular issue comes down to a simple point of logic -- namely, that exactly one of the following statements must be true: 1. There should never be a computer language that has fully open, changeable built-in classes; or, 2. There should be one or more such languages, but Ruby should not be one of them. 3. There should be one or more such languages, and Ruby should be one of them. If #3 is not true, then either #1 or #2 is true, and I don't believe either of them is. If Ruby does away with its openness, then another language will come along that implements that openness. So why not just break the cycle, and decide that Ruby *is* the language that has come along? David -- Rails training from David A. Black and Ruby Power and Light: INTRO TO RAILS (Jan 12-15), Fort Lauderdale, FL See http://www.rubypal.com for details Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)