[ruby-core:31906] Re: Avoiding $LOAD_PATH pollution

> The lookup object pushed onto $LOAD_PATH must respond to #path_for.  The
> feature being required (file name) will be passed in by Kernel#require.

Given the #to_path protocol, I suspect #path_for is a little too
similar. Perhaps #require_path_for / #path_for_require ?

> if RUBY_VERSION > '1.9' then
>   $LOADED_FEATURES << path
> else
>   $LOADED_FEATURES << File.basename(path)
> end

How about appending the absolute path under 1.9?

Say we had a loader object that allowed feature names to be given in
Base64, e.g. `require "bm9rb2dpcmk=\n" would be equivalent to `require
"nokogiri"`. Our loader object would decode the feature name, but
would then want to allow other loader objects, such as RubyGems, to
derive the feature's path. From what I gather, because fancy require
does not recurse with the path it obtains from the loader object, the
loader object would have to handle this recursion itself. In our
example, the loader would call `require` with the decoded feature
name, then return `nil` when re-entered. I'm not sure how I feel about
this.

Anyway, in principle at least, this could be used to commoditise
RubyGems, right? MRI would push a loader object onto the load path
that translated feature names to gem paths, allowing RubyGems to be
just another feature loader. Then, a warning could be issued for
re-defining Kernel.require, so as to encourage the use of this API
instead. How confident are we that this API would be sufficient for
replacing the multiude of require hacks present in the various
RubyGems replacements?