From: Xavier Noria <fxn@...>
Date: 2012-08-08T04:15:16+09:00
Subject: Re: Nesting and constants

--047d7b10cdf96262fa04c6b1cf93
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 7, 2012 at 6:06 PM, Thomas Thomassen <lists@ruby-forum.com>wrote:

The comments there reflects what Matz mentions here:
>
>
> http://www.justskins.com/forums/nested-class-module-namespace-42955.html#post129248
>
> But I still don't understand why this is considered expected behaviour.
>

Well, it is expected behavior because that's the way Ruby works.

A given module can be stored in a hundred constants in dozens of
differently nested constant paths. Constants are largely irrelevant to
Ruby, Ruby semantics are defined around module and class objects.

So, the rule is that whatever module object is opened by the module
keyword, that's what gets pushed to the nesting. It is simple, and it works
in all cases. It does not matter the constant path used to reach the module
object. Given (untested code):

    module M
      N = Module.new
    end

    module A
      module B
        C = M::N
      end
    end

    module M::N
      # (1)
    end

    module A::B::C
      # (2)
    end

    X = M::N
    module X
      # (3)
    end

the nesting in (1), (2), and (3) is the same (M::N). The fact that we got
the M::N module via X or A::B::C is irrelevant. And the fact that we reach
it via M::N is equally irrelevant by the same principle. *Constants do not
matter*, Ruby only cares about the module objects they yield.

In my view all is round and follows those basic axioms, but of course the
only one who can ensure which is the rationale is Matz himself.

--047d7b10cdf96262fa04c6b1cf93
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 7, 2012 at 6:06 PM, Thomas Thomassen <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:lists@ruby-forum.com" target=3D"_blank">lists@ruby-forum.com<=
/a>&gt;</span> wrote:<div><br><div><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

The comments there reflects what Matz mentions here:<br>
<br>
<a href=3D"http://www.justskins.com/forums/nested-class-module-namespace-42=
955.html#post129248" target=3D"_blank">http://www.justskins.com/forums/nest=
ed-class-module-namespace-42955.html#post129248</a><br>
<br>
But I still don&#39;t understand why this is considered expected behaviour.=
<br></blockquote><div><br></div><div>Well, it is expected behavior because =
that&#39;s the way Ruby works.</div><div><br></div><div>A given module can =
be stored in a hundred constants in dozens of differently nested constant p=
aths. Constants are largely irrelevant to Ruby, Ruby semantics are defined =
around module and class objects.</div>

<div><br></div><div>So, the rule is that whatever module object is opened b=
y the module keyword, that&#39;s what gets pushed to the nesting. It is sim=
ple, and it works in all cases. It does not matter the constant path used t=
o reach the module object. Given (untested code):</div>

<div><br></div><div>=C2=A0 =C2=A0 module M</div><div>=C2=A0 =C2=A0 =C2=A0 N=
 =3D Module.new</div><div>=C2=A0 =C2=A0 end</div><div><br></div><div><div>=
=C2=A0 =C2=A0 module A</div><div>=C2=A0 =C2=A0 =C2=A0 module B</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 C =3D M::N</div><div>=C2=A0 =C2=A0 =C2=A0 end</=
div><div>=C2=A0 =C2=A0 end</div>
</div>
<div><br></div><div>=C2=A0 =C2=A0 module M::N</div><div>=C2=A0 =C2=A0 =C2=
=A0 # (1)</div><div>=C2=A0 =C2=A0 end</div><div><br></div><div>=C2=A0 =C2=
=A0 module A::B::C</div><div>=C2=A0 =C2=A0 =C2=A0 # (2)</div><div>=C2=A0 =
=C2=A0 end</div><div><br></div><div>=C2=A0 =C2=A0 X =3D M::N</div><div>=C2=
=A0 =C2=A0 module X</div>

<div>=C2=A0 =C2=A0 =C2=A0 # (3)</div><div>=C2=A0 =C2=A0 end</div><div><br><=
/div><div>the nesting in (1), (2), and (3) is the same (M::N). The fact tha=
t we got the M::N module via X or A::B::C is irrelevant. And the fact that =
we reach it via M::N is equally irrelevant by the same principle. *Constant=
s do not matter*, Ruby only cares about the module objects they yield.</div=
>

<div><br></div><div>In my view all is round and follows those basic axioms,=
 but of course the only one who can ensure which is the rationale is Matz h=
imself.</div></div></div></div>

--047d7b10cdf96262fa04c6b1cf93--