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

Pit Capitain wrote:
> 2008/12/4 Charles Oliver Nutter <[e-mail]>:
>> 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