From: Xavier Noria <fxn@...>
Date: 2010-03-07T19:35:02+09:00
Subject: Re: Class vs Module in constant lookup

On Thu, Mar 4, 2010 at 1:39 AM, Peter McLain <peter.mclain@gemstone.com> wrote:

> Section 11.4.3.2 of the spec discusses Scoped constant references.  Under my
> reading of that section, and our test case, then (following the logic in
> that section):
>
>  (a) the primary-expression is M,
>  (b) M is a module
>  (c 1) XYZ is the constant-identifier
>  (c 2) XYZ is not one of the constants defined in M
>  (c 3 i) There are no included modules in M (skip)
>  (c 3 ii) N/A
>  (c 3 iii) Goto step e of section 11.4.3.1
>
> 11.4.3.1
>  (e) M is not a class
>  (e 1) Search Object for a binding for XYZ
>
> So we *should* find it in Object and MRI is incorrect to return nil.

Or else the spec needs rewording.

Looking for Object for non-scoped constants in modules seems like a
lexical rule to me, akin to searching Module.nesting.

In a scoped constant reference I wouldn't expect lexical-like steps to
be followed, so it might be the case that M::XYZ does not have to look
in Object, while C::XYZ needs to because of the ancestors rule. That
would a posteriori explain MRI's behavior.

We need an authoritative answer, I saw the question was posted to
ruby-core, let's see.