From: Alex Young <alex@...>
Date: 2012-03-20T02:16:11+09:00
Subject: [ruby-core:43477] Re: [ruby-trunk - Feature #4523] Kernel#require to return the path of the loaded file

On 19/03/12 11:58, Luis Lavena wrote:
> On Mon, Mar 19, 2012 at 8:06 AM, Alex Young<alex@blackkettle.org>  wrote:
>> On 18/03/12 10:22, nobu wrote:
>>>
>>>
>>> Issue #4523 has been updated by nobu.
>>>
>>>
>>> I don't think it's useful if it may return false.
>>
>>
>> On the contrary - if it returns false, you know the set of loaded files
>> hasn't changed.  You (should) know that no new ruby has been parsed.
>>
>
> What if your require triggers more requires inside?  The usefulness of
 > you collecting the response of one require doesn't mean you have all
 > the files that were loaded.


This is the sort of thing I have in mind:

   module CollectingRequire
     def require( *args )
       filename = super(*args)
       __log( filename )
       filename
     end

     def __log(filename)
       (@__loaded ||= []) << filename
     end

     def all_loaded
       @__loaded
     end
   end

   extend( CollectingRequire )

   require 'highline'

   all_loaded
     # => [all the files]

That's the sort of arrangement I'd need; I'm sure there are uses which 
don't involve monkeypatching.

I could do just as well with a post-require hook of some sort, but 
that's way more intrusive.  If that's what's needed, though, I'm happy 
to take a look at an implementation.

>>
>>> What's the use case?
>>> I agree that the way to know the loaded path would be useful sometimes,
>>> but this doesn't seem nice.
>>
>>
>> The specific thing I was trying to do was gather all the required files into
>> a SQLite database.  Then a later process with an overridden `require` can
>> load *precisely* the same file content from that database, without
>> ambiguity.
>>
>
> Are you trying to build a list of all the files that were require'd ?
>
> If so, why not use $LOADED_FEATURES with at_exit?

Because when I opened this feature request a year ago $LOADED_FEATURES 
didn't seem to include full paths, so I didn't want to rely on it.

> $LOADED_FEATURES include full paths

Does it?  Is that now part of the spec?  Neither rubinius nor jruby seem 
to make that guarantee, nor is it true for 1.8.7.  And if it is...

  $ irb
1.9.3p125 :001 > $LOADED_FEATURES.first
  => "enumerator.so"

Is that a bug?

> so you can use that combined with $LOAD_PATH to determine the require itself.

I can, and do, already do something like this.  The point is that by 
adding this information to the API, I don't have to - I get a known-good 
value directly from where it's generated, rather than recreating it (and 
possibly screwing it up).  I'm sure I'm not the only one who'd find this 
handy.

If anyone can spot how this proposal can *possibly* be harmful, I'm all 
ears.  As far as I can see it's an unintrusive, useful improvement.

-- 
Alex