alternative approach for dependencies.rb

rubyonrails-core
1

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!!!

2

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.