From: Charles Oliver Nutter Date: 2008-12-05T08:05:36+09:00 Subject: [ruby-core:20336] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly) David A. Black wrote: > 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? Because it isn't today. It might be more open tomorrow, or it might be more closed tomorrow. But this isn't a black-and-white issue, and saying that core class methods provide certain guarantees about behavior does not mean making things any more closed. Here's an example...JRuby doesn't have ObjectSpace enabled by default. You can turn it on, and it works fine, but you pay a performance penalty to allow all objects in the system to be walkable. When we mentioned we were going to have ObjectSpace off by default, a bunch of people raised a fit. And since we started releasing versions of JRuby with ObjectSpace disabled, we've received basically zero bug reports or complaints about it. You *can* make changes that at first glance seem fundamentally "anti-Ruby" without hurting anyone's real-world use of Ruby. So we shouldn't have a knee-jerk policy against such changes...they should be carefully considered rather than rejected out of hand. - Charlie