From: Yehuda Katz <wycats@...>
Date: 2008-12-06T05:36:02+09:00
Subject: [ruby-core:20391] Re: Leave my open classes alone (was Behavior: autoload calls rb_require()  directly)

Again, what is desired is a way to *elect* into this state of affairs  
for performance or stability for a segment of your code.

Sent from my iPhone

On Dec 4, 2008, at 2:53 PM, "David A. Black" <dblack@rubypal.com> wrote:

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