In general, AS::Dependencies has to be seen in a positive way:
AS::Dependencies performs a particular file lookup given a constant missing
in a certain class or module. If I make it, that contract will be
documented in a new guide for 4.2 I am working on.

In particular, AS::Dependencies cannot be seen as an attempt to emulate
Ruby loading algorithms. It is based on const_missing, which does not get
passed two key metadata:

1) The nesting.

2) Whether the missed constant was relative or qualified.

Without that information algorithms cannot be emulated and AS::Dependencies
in consequence does not even pretend to emulate them.

In that sense, my personal opinion is that the special rule you mentioned
that checks A::M to try to guess relative/absolute is so misleading it
should not be there. As your example shows it yields unexpected behavior
(if one expects Ruby rules), and it depends on load order. If by luck that
was already loaded, we act some way, if not yet loaded, in a different way.
That's not good IMO and if it weren't for backwards compatibility I would
be inclined to remove it.

Given all this context, I don't think it would be a good idea to load the
constant your proposal suggests to load. On which grounds would
AS::Dependencies special-case that the rightmost segment would have a
special treatment if it lacks the nesting? And why

    A::B::C::M

should attempt to load A::B::M? That would be really surprising and
AS::Dependencies is not able to distinguish between your example and the
constant path above. All it knows is a constant called "M" has been missing
in a lookup where a class called "A::B::C" is the first element of the
nesting. That's all you know.

It's all very confusing if you see it from a Ruby angle, that's why I
stress you need to forget the Ruby point of view and just program against
the AS::Dependencies contract (unfortunately undocumented, but working on
it).

In general my recommendation is to use relative paths as much as possible,
specially after the class and module keywords, and make judicious use of
require_dependency for edge cases like this.

Xavier

PS: If constant autoloading could be implemented with Kernel#autoload
everything would be consistent, but unfortunately that's impossible due to
a number of reasons.

-- 
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 rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Reply via email to