Nested class/module namespace

[Nathaniel Talbott]

The new ability to declare a class nested in another module (or class)
without actually re-declaring the outer module is cool, BUT:

irb(main):001:0> module M
irb(main):002:1> CONST = "a"
irb(main):003:1> class C
irb(main):004:2> def m
irb(main):005:3> p CONST
irb(main):006:3> end
irb(main):007:2> end
irb(main):008:1> end
=> nil
irb(main):009:0> M::C::new.m
"a"
=> nil
irb(main):010:0> class M::C
irb(main):011:1> def m
irb(main):012:2> p CONST
irb(main):013:2> end
irb(main):014:1> end
=> nil
irb(main):016:0> M::C::new.m
NameError: uninitialized constant M::C::CONST
from (irb):12:in `m'
from (irb):16

Why does the second case fail? It makes me not want to use the second
version, since it means I have to fully-qualify all constants in the
enclosing namespace, instead of just using them as I usually do. I hope it's
just a bug :-/.


Nathaniel

<(><

 

[Yukihiro Matsumoto]

Hi,

In message "Nested class/module namespace"

|Why does the second case fail? It makes me not want to use the second
|version, since it means I have to fully-qualify all constants in the
|enclosing namespace, instead of just using them as I usually do. I hope it's
|just a bug :-/.

Unfortunately, it's not. "class M::C" notation is not a syntax sugar
for 'module M; class C". It is something like "M::C = Class.new", so
that the body of C definition is not nested in the M body.

matz.

 

[Christoph R.]

Kent Dahl wrote:
....

So unless "class M::C" and friends is just meant to be syntactic sugar,
(phoey!) this might help us create cleaner code, IMHO. I wouldn't write
it off as a bug just yet.

I can't help thinking that it might be a feature, not a bug.
Agreed!


Class and module provide namespaces. In the old style, we could not help
but opening all the layers of modules (and thusly their namespaces) when
defining a class within them.

With the new style, we get a cleaner, neater and minimalistic namespace,
where we can include those namespaces we want. (With the exception of
nested classes, but a work-around for that only requires a little
refactoring).

So unless "class M::C" and friends is just meant to be syntactic sugar,
(phoey!) this might help us create cleaner code, IMHO. I wouldn't write
it off as a bug just yet.

The curren new (scoping) rule is simple and straight forward. I am afraid
that a ``resolution's of this bug would complicate things without gaining
much (besides violating the POLS of people growing up with C,Java, etc.
style scoping rules - but Ruby has luckily always done this!)

/Christoph

 

[ts]

Y> Unfortunately, it's not. "class M::C" notation is not a syntax sugar
Y> for 'module M; class C". It is something like "M::C = Class.new", so
Y> that the body of C definition is not nested in the M body.

Well, it has a little problem

If I read parse.y (cpath), this must work, no ?

svg% ruby -e 'class ::C; end'
-e:1: syntax error
class ::C; end
^
-e:1: syntax error
svg%


Guy Decoux

 

[Yukihiro Matsumoto]

i,

In message "Re: Nested class/module namespace"

| Well, it has a little problem
|
| If I read parse.y (cpath), this must work, no ?

But "::Foo = 42" is not allowed either.

matz.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Nested class/module namespace"

|Y> But "::Foo = 42" is not allowed either.
|
| Then was is this case ?
|
|cpath : tCOLON3 cname
| {
| $$ = NEW_COLON3($2);
| }

You are right (as usual). The other bug confused me.
Thank you.

matz.