From: Charles Oliver Nutter <charles.nutter@...>
Date: 2008-12-03T13:50:42+09:00
Subject: [ruby-core:20239] Re: Behavior: autoload calls rb_require() directly

Evan Phoenix wrote:
> 
> On Dec 1, 2008, at 10:36 PM, Yukihiro Matsumoto wrote:
>> This leads another question: should any implementation be affected by
>> basic method replacement, which may make implementation fragile, but
>> more extensible.  For MRI, this is basically protected by calling C
>> functions directly (no dynamic dispatch unless explicitly stated).
>> But for Rubinius, it always use dynamic method calls by definition.
>> The (official) spec will make this "implementation dependent".
> 
> It's a case by case basis. There are certainly places where you want to 
> allow the user to change a method and have it be called. I'm wondering 
> if this is one of those times.
> 
> I don't necessarily see it as making the implementation fragile, since 
> those dynamically invoked methods can do nothing more than a statically 
> invoked method could.
> 
> For now, in Rubinius, we'll go ahead and have Autoload call an internal 
> method that require also calls, to retain compatibility.

Rather than having autoload actually invoke the global require, whatever 
it may be defined as, I think the better change would be the 
long-postponed "require plugin" logic that's been discussed previously. 
Rather than anyone ever needing to redefine require, there should be a 
simple way to add to the require lookup chain with normal Ruby code. 
require overrides have a nasty tendency to break each other, and 
obviously won't fit well into e.g. autoload that wants to make sure it's 
always calling into the "require" that eventually requires files. So 
don't override require, don't make autoload call overridden versions, 
and build in a way to add require plugins without redefining require 
yourself.

It's the right way!

- Charlie