From: Intransition <transfire@...>
Date: 2013-01-11T00:51:13+09:00
Subject: Re: Re-implementing Autoload

------=_Part_1607_1416882.1357833071094
Content-Type: multipart/alternative; 
	boundary="----=_Part_1608_23445860.1357833071094"

------=_Part_1608_23445860.1357833071094
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit



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.


------=_Part_1608_23445860.1357833071094
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<br><br>On Thursday, January 10, 2013 8:55:17 AM UTC-5, Xavier Noria wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Exactly, dependencies.rb does the same as a know trade-off.
<br>
<br>The second bit const_missing lacks is the resolution algorithm that
<br>failed to find the constant.
<br>
<br>Point is, while resolving X in
<br>
<br>&nbsp; &nbsp; module M
<br>&nbsp; &nbsp; &nbsp; X
<br>&nbsp; &nbsp; end
<br>
<br>there is a last step that manually checks Object in spite of Object
<br>not being an ancestor of M, neither belonging to the nesting.
<br></blockquote><div>&nbsp;</div><div>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]?<br>&nbsp;</div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">In
<br>
<br>&nbsp; &nbsp; M::X
<br>
<br>this manual lookup is not performed.
<br>
<br>Thus, in one case you should be able to resolve an autoloded X, and in
<br>the second one you should not, *and you are not told which is the
<br>case*.
<br>
<br>As far as I know, those are the two existing limitations for emulating
<br>constant name resolution within const_missing.
<br>
<br></blockquote><div>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.<br>&nbsp;</div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This is a pity, I would love to rewrite dependencies.rb entirely to
<br>base it in Kernel#autoload and thus removing all these deviations from
<br>the standard way things work, but there are a few blockers. The ones
<br>that motivate your exploration of this topic I am certain. Should
<br>write a post someday about these blockers.
<br>
<br></blockquote><div>I would read! Let me know if you do.<br><br></div>
------=_Part_1608_23445860.1357833071094--

------=_Part_1607_1416882.1357833071094--