module This
module Encompassing
module That
finally_some_really_overly_indented_code
end
end
end
and tried,
module This::Encompassing::That
some_much_less_indented_code
end
since I already do things like,
This::Encompassing::That.module_method
but alas, it didn’t work.
Is there a reason why these two module aspects are not more aligned?
I haven’t looked at the source, but it seems that the module parsing
must already be in place for constructs like This::Encompassing::That,
so what not allow it for defining modules too?
Thanks
···
–
Bil Kleb
NASA Langley Research Center
Hampton, Virginia, USA
module This
module Encompassing
module That
finally_some_really_overly_indented_code
end
end
end
and tried,
module This::Encompassing::That
some_much_less_indented_code
end
since I already do things like,
This::Encompassing::That.module_method
but alas, it didn’t work.
Is there a reason why these two module aspects are not more aligned?
I haven’t looked at the source, but it seems that the module parsing
must already be in place for constructs like This::Encompassing::That,
so what not allow it for defining modules too?
It’s possibly because that notation can mean more than one thing:
module X
module Y
class Z
or
module X
module Y
Z = 100
so there’s no way to determine from the :: notation what you’re
intending to create.
so there’s no way to determine from the :: notation what you’re
intending to create.
Excellent point.
However, since the idea of the “module” keyword is to introduce a new
module or reuse an existing one, I don’t see why the OP’s idea
couldn’t work.
I assumed he meant a kind of autovivification, so that the first
line in a program could be:
module A::C
which would suffer from the ambiguity I mentioned. But if it’s
incremental – i.e., if the above requires that A and B already exist
and be a valid path to a new module definition (namely, C) – that
seems OK.
David
···
On Sat, 15 Feb 2003, Gavin Sinclair wrote:
On Friday, February 14, 2003, 2:00:56 PM, Bil wrote:
so there’s no way to determine from the :: notation what you’re
intending to create.
Excellent point.
However, since the idea of the “module” keyword is to introduce a new
module or reuse an existing one, I don’t see why the OP’s idea
couldn’t work.
I assumed he meant a kind of autovivification, so that the first
line in a program could be:
module A::C
which would suffer from the ambiguity I mentioned. But if it’s
incremental – i.e., if the above requires that A and B already exist
and be a valid path to a new module definition (namely, C) – that
seems OK.
If it makes sense for classes, then well and good. If not, then
error. I would avoid making it too smart (as later messages discuss),
because then you’d be forever explaining it to everybody.
I like the idea of autovivification within certain rules.
class A
end
module A::B
end # error
The rule is that the Xi in
module X1::X2::…::Xn
must all be either:
modules (not classes); or
non-existent (so an empty module can be created)
Gavin
···
On Tuesday, February 18, 2003, 3:13:53 AM, Yukihiro wrote:
Hi,
In message “Re: module This::Encompassing::That” > on 03/02/16, Gavin Sinclair gsinclair@soyabean.com.au writes:
I don’t see a problem with autovivification, though. If the first
line in a program is
module A::C
what conceptually prevents this from being equivalent to
module A
module B
module C
?
Naturally, if A::B is a (non-Module) constant, then an error would
result.
I like the idea of autovivification within certain rules.
class A
end
module A::B
end # error
In this case, it’s not autoviv., because A already exists, so it’s an
explicit creation of B.
But still, why would the above be an error? Why not equivalent to:
class A
module B
end
end
The rule is that the Xi in
module X1::X2::…::Xn
must all be either:
modules (not classes); or
Why not classes?
non-existent (so an empty module can be created)
But it could be an empty Class – meaning, if X2 (or whatever)
doesn’t exist yet, there’s no reason to favor the idea that
it’s supposed to be a Module rather than a Class. There’s just
no way to know.
A case that’s somewhat analogous to this, but without the ambiguity,
is:
mkdir -p a/b/c
which creates all three directories if they don’t exist. In that
case, there’s no ambiguity; there’s nothing else they can be, because
mkdir only does one thing in the first place. But the :: path
notation in module A::C does not have that kind of single meaning.
Of course, C has to be a module, and there are things that A and B can’t be, but there’s more than one thing each of them can be.
I like the idea of autovivification within certain rules.
class A
end
module A::B
end # error
In this case, it’s not autoviv., because A already exists, so it’s an
explicit creation of B.
But still, why would the above be an error? Why not equivalent to:
class A
module B
end
end
Well, you could do that if you like.
The rule is that the Xi in
module X1::X2::…::Xn
must all be either:
modules (not classes); or
Why not classes?
I was over-zealously aiming for simplicity.
non-existent (so an empty module can be created)
But it could be an empty Class – meaning, if X2 (or whatever)
doesn’t exist yet, there’s no reason to favor the idea that
it’s supposed to be a Module rather than a Class. There’s just
no way to know.
The idea of the “module” keyword is to create modules
This entire proposal - autovivification or otherwise - is just syntax
sugar. It meets a common need: to define methods within a nested
module (that already exists) or to create a new nested module (i.e.
only one module is vivified).
Given that, it’s probably best to drop the autovivification idea, and
only allow that the entire path is unambiguous, save for the creation
of a new module.
module A
end
module A::C
end # error
module A::B
end
[…]
Gavin
···
On Wednesday, February 19, 2003, 12:52:44 AM, dblack wrote:
:C