Rails core - Sep 2008 - alternative approach for dependencies.rb

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Sep 5, 2008 at 4:47 AM, Xavier Noria <fxn@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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---