Re: Nested class/module namespace

Kent Dahl [mailto:[e-mail]] wrote:

> Nathaniel Talbott wrote:
>
> > In many cases this form of nesting will create more typing
> > for me than the normal form of nesting!
> 
> Yes, in particular something like these three lines:
> 
> module Constants
> end
> include Fully::Qualified::ModuleName::Constants
> 
> ....where the last line may be repeated. This is a cleaner 
> separation of namespaces anyway. The constants ultimately
> belong inside the classes that use them, not in some
> arbitrary common ancestral namespace area which saves you
> typing.

But that common ancestral namespace isn't arbitrary (and it certainly isn't
just to save me typing): it's a logical separation of my code in to related
parts. If, when I'm doing that separation, I deem that two classes should go
in to the same module, it follows that those two pieces of code are closely
related enough to (a) not worry about namespace clashes, and (b) to need to
easily access one another's namespace. Of course, I still have to qualify
somewhat:

  module M
    class C1
      CONST
    end
    class C2
      def m
        p C1::CONST
      end
    end
  end

I'll admit that I still don't understand what benefit this new behavior
adds, even if I _were_ to separate out my constants in to their own
namespaces and include them. I see doing that as perhaps making this new
behavior bearable, but I don't see any benefit in this new behavior when
working like that.


> > OTOH, I haven't ever had trouble with too much
> > namespace exposure except with top-level classes (like Queue) that 
> > cause confusion when I forget to require something and they 
> > magically get used instead of my classes without an (immediate) 
> > error. But this new form doesn't solve that problem, so I don't
> > see any benefit in how it behaves. Can you give an example where
> > this is beneficial?
> 
> Replace top-level classes with constants (i.e. classes, constant 
> variables, modules etc) anywhere within the module hierachy, and you 
> have one example.

Really?

  module M
    class C1
      CONST
    end
  end

  class C2
    def m
      p CONST
    end
  end

  C2::new.m     => NameError: uninitialized constant C2::CONST

Perhaps:

  module M1
    class C1
      CONST = "a"
    end
    module M2
      class C2
        CONST = "b"
        def m
          p CONST
          p C1::CONST
        end
      end
    end
  end

  M1::M2::C2::new.m    => "b"
                          "a"

That, too, seems to do what one would expect, though. Do you have an example
of namespace pollution?


> Granted, the average Ruby program isn't of such a size that 
> this becomes much of an issue, but once someone writes a
> 10kLOC killer app in Ruby, they will be thankful for proper
> namespace functionality.

Call it personal bias, but whenever an argument is made that a problem will
only show up with a huge code base, I immediately question the validity of
the so-called "problem". The truth is, until someone writes that 10kLOC
project, we don't know. And this is not an issue I've heard is a problem for
any practicioners. As a matter of fact, as a practicioner working on a
fairly large Ruby app, I have no trouble with namespace pollution, and I do
get tired of typing "module x; class x; module x; module x; class x" ad
nauseum. I was hoping this new nesting would save me that, but it doesn't
look like it will. C'est la vi.


> If we can pop over to C++ land for a short while, the "module M;class 
> C;end;end" style opens a namespace scheme that is akin to "#include 
> <m.h>" within c.h. The new style "class M::C;include M::Constants;end"
> has more in common with C++ "using namespace m;". The latter is better 
> in the long run;

But I enjoy programming in Ruby and detest C++; why would I want Ruby to
emulate it? I guess, in summary, I _like_ descendent code having easy access
to constants defined in its ancestors' namespace. I don't think it's a
problem having this behavior (even in large projects), and I think it
provides a lot of benefits. Others are, of course, welcome to think
differently.


> only take in what you are sure you need.

Perhaps this is where we diverge - I'd prefer to make programming easier now
(by perhaps having more than I need) rather than prematurely fix problems I
think I _might_ have.


Nathaniel

<:((><