From: Xavier Noria <fxn@...>
Date: 2013-01-10T22:55:17+09:00
Subject: Re: Re-implementing Autoload

On Thu, Jan 10, 2013 at 2:08 PM, Intransition <transfire@gmail.com> wrote:

> Thanks Xavier. I realize implementation differs. Clearly I can't tap into
> the underlying constant resolution with pure Ruby. But I expected that I
> should be able to emulate it effectively with const_missing --I would think
> it would possible to get essentially the same results.
>
> The only difference I am sure about at this point, is that I haven't been
> able to find a way to get `Module.nesting`, instead I had to resort to
> Constant#name and splitting it up.

Exactly, dependencies.rb does the same as a know trade-off.

The second bit const_missing lacks is the resolution algorithm that
failed to find the constant.

Point is, while resolving X in

    module M
      X
    end

there is a last step that manually checks Object in spite of Object
not being an ancestor of M, neither belonging to the nesting.

In

    M::X

this manual lookup is not performed.

Thus, in one case you should be able to resolve an autoloded X, and in
the second one you should not, *and you are not told which is the
case*.

As far as I know, those are the two existing limitations for emulating
constant name resolution within const_missing.

This is a pity, I would love to rewrite dependencies.rb entirely to
base it in Kernel#autoload and thus removing all these deviations from
the standard way things work, but there are a few blockers. The ones
that motivate your exploration of this topic I am certain. Should
write a post someday about these blockers.