alternative approach for dependencies.rb

[Xavier Noria]

I am playing around with an alternative approach for dependencies.rb I
commented a while back but I've found something that may be a stopper.
I'd like to explain it in case anyone sees a way to handle this.

The basic idea would be that at some point in the initialization we
traverse load_paths and make autoload calls like this:

autoload "User", "app/models/user.rb"

To remove that constant in development mode you do the same stuff as
now and remove "app/models/user.rb" from $" or some hack like that
(because autoload uses require). I believe that would simplify
dependencies.rb quite a bit.

OK, problem as always is namespaces. Let's suppose you have
admin/product.rb. I'd like to be able to say

autoload "Admin::Product", "admin/product.rb"

but It turns out that autoload only accepts constant names, that call
is invalid. To say that you need to have a true Admin module and then
it is OK to say

module Admin
autoload "Role", "admin/role.rb"
end

If there's no admin.rb you can just create an Admin module on the fly
and go on, but if there's one you should load it.

And that doesn't fit because a user would expect to be able to use
constants in admin.rb and there's no guarantee those are ready for
autoloading because we are in the middle of the recursion.

Argh!!!

[Xavier Noria]

On Fri, Sep 5, 2008 at 4:47 AM, Xavier Noria <f...@hashref.com> wrote:

> If there's no admin.rb you can just create an Admin module on the fly
> and go on, but if there's one you should load it.
>
> And that doesn't fit because a user would expect to be able to use
> constants in admin.rb and there's no guarantee those are ready for
> autoloading because we are in the middle of the recursion.

I thought about rescueing NameError and deferring those loads until
they would eventually resolve by themselves, but admin.rb and
admin_prime.rb could point to each other and that wouldn't be
solvable.

But I've seen another issue: Currently initializers are able to use
autoloaded constants, so that tree traversal should be done before
they run. But admin.rb may assume initializers have been run.

I believe this is indeed a stopper.