On Dec 1, 2008, at 10:36 PM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: [ruby-core:20190] Behavior: autoload calls  
> rb_require() directly"
>    on Tue, 2 Dec 2008 02:54:36 +0900, Evan Phoenix <evan / fallingsnow.net 
> > writes:
>
> |While working on some specs, we found out that autoload
> |(Kernel#autoload and Module#autoload) internally call rb_require()
> |directly to pull the file in. This of course means that if
> |Kernel#require has been changed (for instance by rubygems) that the
> |changed logic won't be run.
> |
> |My question is if it's intentional that autoload bypasses
> |Kernel#require. If not, autoload should probably use rb_funcall() to
> |keep everything consistent.
> |
> |This obviously also effects Rubinius, as our autoload just calls
> |Kernel#require directly.
>
> 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.

Thanks!

  - Evan Phoenix

>
>
> 							matz.
>