Ruby (and Rails) nested module syntax

Question

I'm wondering what the difference is between the following two modules

# First Example
module Parent
  module Child
  end
end

and

# Second Example
module Parent::Child
end

Using the 2nd method, it appears as though the Parent module must be previously defined, otherwise I get an 'uninitialized constant' error

Given this, what is the preferred way of defining modules such as this and then adding nested children with regards to syntax and file structure (ie. folders etc). Reference to a Rails way would be greatly appreciated.

Are these two examples for all intents and purposes equivalent?

Ryan Bigg · Accepted Answer · 2010-05-19 21:38:36Z

34

In the first example, it defines the Parent module and then the Child module. The second example, as you say yourself, must have the Parent module defined before hand. At the expense of one more line of code, you ensure that the module that you're nesting under by using your first example is always going to be defined.

For a Rails example let's look into the railties/lib/rails/engine.rb file which re-opens the Rails module and then defines an Engine class inside of it. This could have been done with simply:

class Rails::Engine

But instead perhaps for the reasons stated above and perhaps also for clarity's sake, the module was defined first, then the class inside.

answered May 19, 2010 at 21:38

Ryan Bigg

108k25 gold badges243 silver badges264 bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

thomthom Over a year ago

An important note is what @banister mentioned - that access to constants in is different.

horseyguy · Accepted Answer · 2010-05-20 07:07:25Z

15

I prefer the second method (if im sure that Parent is already defined) because it looks cleaner, esp. when the nesting is very deep.

However the 1st method has some advantages, one not yet discussed is that a nested module gets access to any lexically available constants in the enclosing module.

answered May 20, 2010 at 7:07

horseyguy

30k20 gold badges110 silver badges151 bronze badges

Comments

blocktator · Accepted Answer · 2010-05-20 00:34:43Z

7

Generally speaking, you don't want to define a module using the module Parent::Child syntax unless you can be absolutely certain that Parent is already there. A sub-Module can only be defined using the :: syntax if the parent module is defined. In your example, if you do the following, you will not get an uninitialized constant error.

module Parent
end

module Parent::Child
end

answered May 20, 2010 at 0:34

blocktator

1362 bronze badges

Comments

TauPan · Accepted Answer · 2011-11-22 09:57:01Z

3

It seems that Banister's answer is also the reason for this behaviour:

ruby-1.9.2-p290 :001 > module A; module A; A.ancestors; end; end
 => [A::A] 
ruby-1.9.2-p290 :002 > module A::A; A.ancestors; end
 => [A]

The inner module A is a constant inside the outer module A, and thus it's not visible using the second method.

Editing my previous comment:

This is explained in 7.9 "Constant Lookup" of "The Ruby Programming Language" (First Edition). The relevant part here is Module.nesting, which doesn't contain the outer module in the second example, thus A can only be found in the global scope.

edited Nov 22, 2011 at 9:57

answered Nov 21, 2011 at 20:57

TauPan

1416 bronze badges

Comments

software_writer · Accepted Answer · 2023-02-02 02:53:12Z

There are three ways in which the second version (A::B) differs from the first:

It assumes that the outer module, i.e. A is already defined. If it's not, Ruby will throw a NameError: uninitialized constant A error. So use this syntax only if you're sure that module A exists.
It allows you to reduce the amount of indentation. Instead of 3 levels of indentation, only one is necessary.
You can not access the constants defined inside module A inside module B without the scope resolution (::) operator. This is a significant difference; the next section covers it in detail.

Accessing Constants in Nested Modules

The scope of constant access is different depending on how the nested module is defined. Let's consider the first version.

module A
  Z = 10
  
  module B
    puts Z
  end
end

# output 
10

Let's try accessing the constant in a module defined using the second syntax. It throws a NameError.

module A
  Z = 10
end

module A::B
  puts Z
end

# output
uninitialized constant A::B::Z (NameError)

Here, you've to access it using the scope resolution operator (::) as follows:

module A
  Z = 10
end

module A::B
  puts A::Z
end

# output
10

Module Nesting

The Module.nesting method returns the list of modules nested at the time of call. The following example shows how the two versions differ in their module nesting.

module A
  p Module.nesting  # [A]
  
  module B
    p Module.nesting  # [A::B, A]
  end

  module B::C
    p Module.nesting  # [A::B::C, A]
  end
end

module A::D
  p Module.nesting  # [A::D]
end

When module D is defined, the nesting does not include module A. Hence, module D cannot access the constants defined in module A, without explicitly using the scope resolution (::) operator.

Source: Nested Modules in Ruby

Collectives™ on Stack Overflow

Ruby (and Rails) nested module syntax

5 Answers 5

1 Comment

Comments

Comments

Comments

Accessing Constants in Nested Modules

Module Nesting

Comments

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

5 Answers 5

1 Comment

Comments

Comments

Comments

Accessing Constants in Nested Modules

Module Nesting

Comments

Your Answer

Sign up or log in

Post as a guest

Linked

Related