Ruby doesn't have real modules. You're right, that they are just namespaces. They are global variables with extra typing.

If you use a third party library, when you require something, you have no idea what "modules" or other values it creates polluting the global namespace. This at least assigns those values to a local variable where they can be accessed and doesn't make them global.

That said, I'm not a fan of ruby and all the workarounds to try to make it like a more sane language that it isn't.

It allows you to namespace things that aren't themselves namespaced. That way you can just require things that, might say, have the same module names as your own code without worry. I'm curious if this namespace mechanism could, say, isolate monkey patches. Probably not, but it would be nifty.

Namespace isolates monkey patches.

>I'm curious if this namespace mechanism could, say, isolate monkey patches.

Wasn't that the purpose of refinements? Perhaps I am misremembering, because I never had a need to reach for refinements myself.

You still need to rely on the library maintainers to use them. This mechanism allows you to sandbox a library that doesn't.

Ok, understood. This being into account, would it not even better to make the most obvious way to code some logic most likely shaped without this issue in the first place.

Because, if the external dependency smells that bad, what the root cause? If that is crap code produced thus for some reason (unskilled/over-time-bound-pressured person for example), then probably this is better to avoid using this code altogether. And if this is instead because the language encourage easy path with bad outcomes, then it might make more sense to make a proposal with a facility to instead make the path of least resistance be something of more enjoyable outcome.

Proper namespaces are a good thing to have regardless. Relying on gem maintainers to not pollute the main namespace was always suboptimal.

Using Ruby modules to namespace things is certainly possible, but is very often cumbersome. Modules also "hardcode" a namespace: that is, if I use modules for name-spacing, it will always be "MyModule::MyClass" everywhere -- or, in other words, namespacing is controlled by library author, not user. The proposed feature shifts that control to library user.

> if I use modules for name-spacing, it will always be "MyModule::MyClass" everywhere

It will be identified as such by e.g. the default `inspect`, but nothing stops you from `include`-ing MyModule into another module or class, or even the global scope so that you can reference MyClass without MyModule.