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

What is desirable is a user option that could turn on more static  
features for a segment of code without affecting ruby proper.

Sent from my iPhone

On Dec 4, 2008, at 2:46 PM, Charles Oliver Nutter <charles.nutter@sun.com 
 > wrote:

> Pit Capitain wrote:
>> 2008/12/4 Charles Oliver Nutter <charles.nutter@sun.com>:
>>> 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".
>> And who decides which things are more important than the others?  
>> Based
>> on which criteria? I'd say the Ruby language doesn't need more
>> dogmatism about things like performance and memory efficiency.
>
> You are entitled to your opinion. :)
>
>>> 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.
>> So I couldn't add some logging or tracing to Fixnum#+? This looks
>> pretty closed to me.
>
> Perhaps you would be able to in a less restrictive mode. Perhaps as  
> Michael proposed there could be a library to load for either case,  
> or there could be a CLI flag. There's plenty of options to  
> accommodate both people who want to monkey-patch core classes and  
> people want to avoid the overhead that comes from allowing that  
> monkey-patching.
>
>>> 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.
>> If you want to prevent this, you have to close almost all core
>> methods. Is this what you are proposing? Why is the current
>> Fixnum.freeze not enough?
>
> You would not have to close almost all core methods. And  
> Fixnum.freeze closes the whole class, so you're going too far in  
> this comparison.
>
>>> Ruby needs to grow up as a language by allowing people who want  
>>> guarantees
>>> to get guarantees.
>> Says who? If you want to change Ruby in such a fundamental way, why
>> should it still be called Ruby?
>
> Matz proposed introducing some sort of protection for core code.  
> Whether that comes in the form of locking down Fixnum#+ or adding  
> some new Fixnum#__ADD__ or namespacing is a detail.
>
>>> And there's a lot of people who want some minimal, basic
>>> guarantees about core classes.
>> Do you have any references for this claim? I'm definitely not in  
>> this group.
>
> If nobody were interested in it, it wouldn't keep coming up. There's  
> certainly plenty of references in the ML logs.
>
> FWIW, I don't expect this sort of thing to ever get into core, so  
> the JRuby and Ruby 1.9 strategy of watching for changes to core  
> classes is probably as close as we will get. And that's ok...in both  
> cases we can get very good performance without locking down e.g  
> Fixnum#+. But it makes pushing Ruby performance farther than what we  
> have today a lot more complicated.
>
> - Charlie
>