On Thursday, January 10, 2013 8:55:17 AM UTC-5, Xavier Noria wrote: > > > 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. > Ah, thanks. I've incorporated that into my implementation. I assume it's just looks in Object in this case and not all it's ancestors [Object, Kernel, BasicObject]?
> 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. > > But does this explain the error I get with `bundle exec`? That's what I don't understand still. I don't think this one difference accounts for it. Maybe it does, but I don't see how. And if it does not, then there remains something else amiss. > 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. > > I would read! Let me know if you do. -- You received this message because you are subscribed to the Google Groups ruby-talk-google group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at https://groups.google.com/d/forum/ruby-talk-google?hl=en
