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
<:((><
···
Kent Dahl [mailto:kentda+news@stud.ntnu.no] wrote:
But anyway.)
:C syntax worked, it would not be adding