From: Run Paint Run Run Date: 2010-08-28T19:30:30+09:00 Subject: [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?