On Wed, 19 Sep 2001, Yukihiro Matsumoto wrote:

> I'm not sure what is your point.  If you really want to read from the
> current directory hierarchy (which is pretty unreliable), you can
> prepend "." to $LOAD_PATH variable.

The idea is that I want to split a project between multiple files.
Generally speaking, it's convenient to have exactly one class per file and
each class implemented in only one file.  In other words, if I have a
class Foo and a class Bar, then class Foo gets put in Foo.rb and class Bar
gets put in Bar.rb.

Now consider that Foo inherits from or otherwise depends on Bar.  Then in
Foo.rb, I'm likely to put:

  require 'Bar.rb'

Now consider that Foo.rb does a little bit more than just define a class
Foo; in fact I would like to do this:

  [paul@zaphod ~/foo] ruby Foo.rb

This should work just fine, provided that both Foo.rb and Bar.rb are in
the ~/foo directory.  If however, I want to do this:

  [paul@zaphod ~/] ruby foo/Foo.rb

Then this will not work, because the interpreter cannot find Bar.rb.  Thus
I have to use a hack of finding the directory name of __FILE__ to get Ruby
to find the file.  This is not at all convenient.

> Wait a second.
>
> |  require 'foo.rb'
> |  require 'foo'
>
> does not load twice.  In your example, you loaded a file using
> different path.  Normalizing loaded path is a good thing to see, but I
> don't think it's mandatory.

You are right.  I was confusing this with:

  require 'foo.rb'
  require './foo'

which I have mistakenly done in the past.

> |Ideally, require would do the following:
> |
> |  1) Check for the ./ prefix; if it is there, look in the same directory
> |     as __FILE__.
>
> I don't agree with this.  This changes "." semantics.

This is true.  As an alternative, all of my programs use a function called
"requirelocal" to require a file out of the same directory as the file
being executed.  There's also an equivalent "loadlocal" that is used less
often.

> |  2) Check to see if the file is a symlink; if it is, get the name of the
> |     real file being required.  Repeat as necessary.
> |  3) Find the full pathname of the file being required before marking the
> |     file as already having been required.
>
> I'm not sure above 2) and 3) are worthy enough, considering loading
> from current working direcotry is not recommended.
>
> 							matz.

It's not just about loading from the CWD.  On my machine,
/usr/local/lib/ruby/1.6 is already cluttered with a number of files.  I
can easily add new directories, which is fine (e.g. with 'net/ftp' et
al.), but what if a script in the 'net' directory wants to load another
script from the 'net' directory?  It doesn't really make sense for that
script to have to require 'net/foo', since that requires the script to
know where it is placed (or to deduce that information).

Since require is not an operation that is performed often, it makes sense
to me to make checks 2) and 3), since they are likely to make code more
robust.

Paul