headers
Mark Wilden | 15 May 04:25

Method lookup for modules included in modules

My question has to do with the diagram on page 12 of "Advanced Rails".  
It arises from the following structure:

module A; end;
module B; include A; end
module C; include A; end
class D; include B; include C; end

(This would be a diamond-shaped hierarchy if inheritance were used.)  
Now picture a similar structure, except without a common ancestor:

module A1; end;
module A2; end;
module B; include A1; end
module C; include A2; end
class D; include C; include B; end

d = D.new

When a message is sent to d, that method is searched for in the  
following order: B, A1, C, A2. My question is how this is implemented  
in terms of 'klass' and 'super' as described in the book.

First, the klass pointer from d takes us to D, whose m_tbl is  
searched. Then D's super pointer takes us to the proxy for the B  
module. That proxy's m_tbl pointer points to the B methods which are  
searched. Then B's super pointer takes us to B's proxy for the A1  
module, which causes A1's methods to be search.

Here's my problem. If A1 doesn't contain the method, what causes the
(Continue reading)

Permalink | Reply |
headers
7stud -- | 15 May 06:10
Picon
Favicon

Re: Method lookup for modules included in modules

Mark Wilden wrote:
> My question has to do with the diagram on page 12 of "Advanced Rails".

Then why wouldn't you post your question in a Rails forum??!
--

-- 
Posted via http://www.ruby-forum.com/.
Permalink | Reply |
headers
Rick DeNatale | 15 May 12:53
Picon

Re: Method lookup for modules included in modules

On Thu, May 15, 2008 at 12:10 AM, 7stud -- <bbxx789_05ss <at> yahoo.com> wrote:
> Mark Wilden wrote:
>> My question has to do with the diagram on page 12 of "Advanced Rails".
>
> Then why wouldn't you post your question in a Rails forum??!

Because, if you read past he first line, you'd realize that it is
definitely a Ruby and not a Rails question.

--

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/
Permalink | Reply |
headers
ara.t.howard | 15 May 07:05
Picon
Gravatar

Re: Method lookup for modules included in modules


On May 14, 2008, at 8:29 PM, Mark Wilden wrote:

>
> Here's my problem. If A1 doesn't contain the method, what causes the  
> search to backtrack to the B proxy and follow its super pointer to  
> the C proxy? This "backtracking" seems counter to the purported  
> "linear" lookup order. (This is just a conceptual problem for me -  
> it's obvious what the lookup order is, and it's easy to verify.)

as each module in included in the target, it's entire lookup chain is  
added to that target - therefore no 'backtracking' is required, we  
just end up with a long line that, when followed, happens to give the  
appearance if backtracking.

a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama
Permalink | Reply |
headers
Mark Wilden | 15 May 16:59

Re: Method lookup for modules included in modules

On May 14, 2008, at 10:05 PM, ara.t.howard wrote:

>> Here's my problem. If A1 doesn't contain the method, what causes  
>> the search to backtrack to the B proxy and follow its super pointer  
>> to the C proxy? This "backtracking" seems counter to the purported  
>> "linear" lookup order. (This is just a conceptual problem for me -  
>> it's obvious what the lookup order is, and it's easy to verify.)
>
> as each module in included in the target, it's entire lookup chain  
> is added to that target - therefore no 'backtracking' is required,  
> we just end up with a long line that, when followed, happens to give  
> the appearance if backtracking.

I do understand that that's how it works in practice. I was trying to  
understand the process in terms of its implementation via proxies,  
klass, super and m_tbl. If it were truly implemented as a single long  
chain, then that would require (in my example) that the A2 proxy's  
super points to the B proxy. Hmmm....I wonder if that's indeed the  
case, as you imply?

///ark
Permalink | Reply |
headers
Rick DeNatale | 15 May 22:24
Picon

Re: Method lookup for modules included in modules

On Thu, May 15, 2008 at 10:59 AM, Mark Wilden <mark <at> mwilden.com> wrote:
> On May 14, 2008, at 10:05 PM, ara.t.howard wrote:
>
>>> Here's my problem. If A1 doesn't contain the method, what causes the
>>> search to backtrack to the B proxy and follow its super pointer to the C
>>> proxy? This "backtracking" seems counter to the purported "linear" lookup
>>> order. (This is just a conceptual problem for me - it's obvious what the
>>> lookup order is, and it's easy to verify.)
>>
>> as each module in included in the target, it's entire lookup chain is
>> added to that target - therefore no 'backtracking' is required, we just end
>> up with a long line that, when followed, happens to give the appearance if
>> backtracking.
>
> I do understand that that's how it works in practice. I was trying to
> understand the process in terms of its implementation via proxies, klass,
> super and m_tbl. If it were truly implemented as a single long chain, then
> that would require (in my example) that the A2 proxy's super points to the B
> proxy. Hmmm....I wonder if that's indeed the case, as you imply?

module A1; end;
module A2; end;
module B; include A1; end
module C; include A2; end
class D; include C; include B; end

results in the chains:

A1
A1
(Continue reading)

Permalink | Reply |

Gmane