[choward]

Your claiming anything wrapped in a module block is a module. My point is that they aren't "real" modules. I know it's debatable what a module is but Ruby's don't meet my definition. Here's why:

Let's say a file had a module in it. It can behave differently based on context.

For example, let's say I have a module A that requires modules B and C. Module C could use module B without explicitly pulling it in because modules are just globals. However, if a different module just requires module C but not module B and no other files required B either, then module C would break when it tries to use model B. If modules weren't global B, would have to require it to use it directly regardless but since it doesn't it's easy to get unexpected results.

In ruby a file doesn't have to declare the modules it uses which is why I don't consider them modules but just global namespaces. So if another module that got required earlier happens to require B, then B can be used because it's just a global.

I'm summary, modules in Ruby aren't modules but just global namespaces.

[jonnytran]

When I was new to Ruby and hadn't learned the available tools yet, I had similar problems because I brought practices from other languages that didn't work.

Typically, what you're describing is solved, in different ways depending on your setup. I literally never think about the issue you're describing when using Ruby.

- With Rails/ActiveSupport in development mode: Module B is autoloaded lazily when C refers to it.

- With Rails/ActiveSupport in production mode: All modules are eagerly loaded at startup.

- Plain Ruby: There's a few ways, but most gems simply have a file at the top level that eagerly requires all files when the gem is required. Same with an app.

If startup time becomes an issue, you can configure the autoloading at the top level, and the appropriate file will be required lazily when it's referred to. But at that point, just use ActiveSupport.