On Mar 19, 2012, at 10:16 AM, Alex Young wrote:
> 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:
>>>>=20
>>>>=20
>>>> Issue #4523 has been updated by nobu.
>>>>=20
>>>>=20
>>>> I don't think it's useful if it may return false.
>>>=20
>>>=20
>>> 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.
>>>=20
>>=20
>> 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.
>=20
>=20
> This is the sort of thing I have in mind:
>=20
>  module CollectingRequire
>    def require( *args )
>      filename =3D super(*args)
>      __log( filename )
>      filename
>    end
>=20
>    def __log(filename)
>      (@__loaded ||=3D []) << filename
>    end
>=20
>    def all_loaded
>      @__loaded
>    end
>  end
>=20
>  extend( CollectingRequire )
>=20
>  require 'highline'
>=20
>  all_loaded
>    # =3D> [all the files]
>=20
> That's the sort of arrangement I'd need; I'm sure there are uses which =
don't involve monkeypatching.
>=20
> 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.

There's an easier way that works without any monkey patching or new =
features.

ruby -e 'loaded =3D $LOADED_FEATURES.dup; require "highline"; p =
$LOADED_FEATURES - loaded'

>>>> 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.
>>>=20
>>> 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.
>>=20
>> Are you trying to build a list of all the files that were require'd ?
>>=20
>> If so, why not use $LOADED_FEATURES with at_exit?
>=20
> 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.
>=20
>> $LOADED_FEATURES include full paths
>=20
> Does it?  Is that now part of the spec?

Yes.

> Neither rubinius nor jruby seem to make that guarantee,

They do.

> nor is it true for 1.8.7.

1.9.1, 1.9.2 and 1.9.3 have been released since 1.8.7, so I don't know =
why you would check 1.8.7 for new features.  jruby and rubinius follow =
the 1.8 spec when run in 1.8 mode, and the 1.9 spec when run in 1.9 =
mode.

>  And if it is...
>=20
> $ irb
> 1.9.3p125 :001 > $LOADED_FEATURES.first
> =3D> "enumerator.so"
>=20
> Is that a bug?

I would argue no as enumerator.so is a dummy require:

  rb_provide("enumerator.so");	/* for backward compatibility */

to allow old 1.8 programs to continue to require 'enumerator' which is =
now built-in in ruby 1.9.

>> so you can use that combined with $LOAD_PATH to determine the require =
itself.
>=20
> 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.
>=20
> 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.

It only returns the filename directly loaded, not the complete set of =
files required, so can only return limited information.

It only returns the filename if this was the first time the file was =
required.  It feels bad that this feature would only work on the first =
require which the user may not be able to control.

It promotes needless monkey patching or overriding of require when there =
is a simple solution to retrieve the information you desire (the set of =
files loaded, per your example above).

For these reasons, I don't think it encourages good use of ruby.=