Re: Kernel#autoload vs require_relative

On Thursday, June 16, 2011 11:50:57 AM Piotr Szotkowski wrote:
> Hm, I do prefer using require_relative over require + $LOAD_PATH
> changes; it looks cleaner to me and doesn=E2=80=99t touch shared
> globals, but I guess that=E2=80=99s more of a personal preference.

So, while writing the rest of this (long) post, I think I actually dug up a=
=20
solution for you, in the form of the 'autoloader' gem I wrote awhile back:

https://github.com/masover/autoloader

If everything in your 'lib' hierarchy is normally loaded via autoload, and=
=20
follows a decent naming convention, I think this solves your problem. In yo=
ur=20
example, somewhere in 'lib/foo.rb', you could do this:

  require 'autoloader'
  AutoLoader << File.dirname(__FILE__)

  module Foo
    include AutoLoader
  end

Ok, there's some __FILE__ ugliness, but in exchange, you automagically get=
=20
'autoload' statements generated for everything, and you don't have to modif=
y=20
your load path.

Caveat: I wrote this awhile ago, when Merb was still a thing. It seems to=20
still work, but you might still want to read it to understand what it does.=
=20
It's not that long:

https://github.com/masover/autoloader/blob/master/lib/autoloader.rb

> What I was trying to ask is whether there couldn=E2=80=99t be
> a Kernel#autoload_relative call or a =E2=80=98relative: true=E2=80=99
> optional parameter to Kernel#autoload to make it symmetric
> with the require/require_relative combination...

There is one thing I would _much_ rather have than this: Enough hooks into=
=20
either the language or the autoload mechanism so that things like this are=
=20
possible to do entirely inside Ruby.

That is: Currently, we have const_missing, but it isn't called when someone=
=20
tries to define a constant. For example, if I have Rails-style const_missin=
g=20
hacks, and I want to re-open a previously-defined module, I need to do this:

  Foo::Bar.module_eval do
    ...
  end

instead of:

  module Foo
    module Bar
      ...
    end
  end

The latter will never hit const_missing, and would thus never load foo.rb o=
r=20
whatever. And sure, if I'm re-opening Bar, I'm probably better off defining=
 a=20
separate module and forcing Bar to include it. But what if this is inside=20
foo/bar.rb? Now if I say

require 'foo/bar'

I'll get Foo::Bar, but I won't ever load foo.rb -- whereas, say,

  Foo.module_eval do
    module Bar
      ...
    end
  end

=2E..ew.

Anyway, what I really want is something like:

  autoload :Foo do
    # block to ensure Foo is defined
  end

In this case, autoload is the wrong word, but this would let me write the=20
ultimate autoload-based replacement for the old Rails const_missing hack. W=
hat=20
I have now is in the 'autoloader' gem:

AutoLoader << '/path/to/lib'

It will crawl 'lib' one level deep, take every '.rb' file, and create an=20
'autoload' tag for it. But in order to map Foo::Bar to 'foo/bar.rb', I stil=
l=20
need the user to have a foo.rb file which does some extra work:

module Foo
  include AutoLoader
end

I can't think of any way to make this work other than having some callback=
=20
fire when the file actually gets loaded. Last I checked, Kernel#autoload wo=
uld=20
call 'require' from C when fired, so overloading 'require' doesn't help. An=
d=20
const_missing isn't a substitute, nor is there any way to duplicate=20
Kernel#autoload's functionality from Ruby.

I actually think autoloading via require_relative is a bad idea, versus jus=
t=20
adding something to the load path. Some people think autoload itself is a b=
ad=20
idea. There are probably workarounds enough for both of us. But it does=20
frustrate me that Kernel#autoload is so inflexible, and it really doesn't s=
eem=20
like it needs to be.