From: Charles Oliver Nutter <charles.nutter@...>
Date: 2007-10-20T01:27:29+09:00
Subject: Re: Import gem to Ruby 1.9

NAKAMURA, Hiroshi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I think there's a consensus about the need.  Nobu's idea is here;
> (translation of [ruby-dev:31321])
> 
>   Following is an abstract processes of the current behavior of require;
> 
>     def require_internal(feature)
>       exts = loadable_exts(feature)
>       found = nil
>       $LOAD_PATH.find {|path| found = find_file(path, feature, exts)} or
>         raise LoadError, "no such file to load -- %s", feature
>       load_file(found)
>     end

What would find_file look like?

def find_file(feature, exts)
   exts.each {|ext| file = ext.find_feature(feature); return file if file}
   nil
end

So there's one way...and then a given ext would just need to implement 
find_feature (or whatever the name is).

This seems like the right approach, since it explicitly takes the 
chaining out of the hands of require extenders.

>   And a proposal is that when a path from $LOAD_PATH is not a String, do
>   the following.
> 
>     path.find_file(feature, exts)
>     found.load_file()

This is interesting. Won't it require checking every object in every 
require along the way?

> Do you have an actual example?  RubyGems replaces require and
> Rails(ActiveSupport) overrides it but they live together.  I think Rails
> took care of rubygems' behavior.

I don't have one in-hand, no, but the prevailing recommendation I've 
seen is "don't override require because you'll break something". Rails 
and RubyGems work fine together, but I've seen other folks override 
require and break both, largely getting scared off. The problem is the 
implicit requirement to call the next hook in the chain by aliasing and 
calling require, which the above proposal eliminates.

- Charlie