[ruby-core:20366] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

HriI --

On Fri, 5 Dec 2008, Charles Oliver Nutter wrote:

> 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.

The danger, though, is of enshrining what people have done so far with
Ruby as being the permanent comfort zone of the language. It reminds
me of the thing where the administration of a college wait until
enough people have walked across the grass along a certain path, so
that there's just dirt, and then, having seen where people walk, they
pave that route and put a "Keep off the grass" sign on the rest :-) I
know no one is talking about that degree of change, but I do think
there's a risk to trying to decide or delimit the real-world practices
up front.

Mind you, I am personally very conservative about making core changes.
I tend to advocate #extend as the best way to change the behavior of
an instance of a core class. My kid-in-a-candy-store days are long
behind me :-)


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)