Hi,
I have a specific case where the rails constant loading algorithm seems to
be not optimal. Here is an example:
Suppose there are constants A::M and A::B::M, defined in correctly-named
files in the autoload path. Assume A::B::M has not yet been loaded. When
the following is loaded:
module A::B
class C
M
end
end
There are two possible behaviours, based on whether or not A::M has been
loaded.
This seems unexpected and is frequently undesirable to me. I would expect
A::B::M to be loaded by missing constant loading algorithm.
So, we have two cases:
1) A::M is not already loaded
Rails tries to load, in order, A::B::C::M, A::B::M, A::M, ::M
2) A::M is already loaded
Rails tries to load only A::B::C::M. The missing constant loading algorithm
will attempt to load A::B::C::M, which fails. However, because A::M exists,
it will not attempt to load A::B::M, and a name error is raised.
The (vanilla) ruby order for these constants would be: A::B::C::M, A::B::M,
::M
It seems to me that case 2) is not optimal, and not hard to fix. Because
A::M is defined but was not loaded by ruby (that is, A was not part of
Module.nesting and so const_missing was invoked), we know that A::M is not
what would be referenced according to the ruby constant rules. However, it
seems that it would be preferable to attempt to load A::B::M, to be more in
line with case 1. It also seems reasonable to attempt to load ::M.
These are things that the const loading algorithm seems as though it could
do, and I am willing to make a patch for that. Is there something I'm
missing here, or some reason it does not attempt to load these constants?
Arron
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
