Issue #21311 has been updated by byroot (Jean Boussier). While I believe namespaces would be a good addition to Ruby, I'm not convinced this particular implementation of namespaces is what Ruby needs. First, I'm not convinced by the motivations:
Avoiding name conflicts between libraries: Applications can require two different libraries safely which use the same module name.
Is this a problem that happens on a regular basis? I believe Ruby has a pretty well established convention for libraries to expose a single module with a name that correspond to their gem name. Actual top level module name clashes are extremely rare in my experience.
Avoiding unexpected globally shared modules/objects
Here again, from my experience this is very rare, and usually accepted as a bug, and promptly fixed. Do we have concrete cases of this being a peristent problem?
Multiple versions of gems can be required
I remember there was discussions about this in the past. Personally this is a feature it's quite strongly against because it's extremely hard to reason about. If you have library A using the gem G in version 1, and library B using the gem G in version 2, and end up with A being passed a G-v2 object, you may end up in a world of hurt. I understand this feature would be useful for bundler specifically to allow them to use gems internally without conflicting with the application (a problem they currently solve by vendoring), but outside of that I'm not convinced it's a desirable feature. I get that it can happen that you end up in a sticky situation with two dependencies being essentially incompatible because they require conflicting versions of another dependency, as it happened with the Faraday 2 transition a few years back, but I'm not convinced that working around the problem that way is a net positive.
Namespace monkey patches
This one isn't in your ticket, but from previous public talks I understand it is one? Here again I'd like to question how big of a problem monkey patches really are. It is true that 15 years ago, numerous popular gems would irresponsibly monkey patch core classes, but I believe these days are long gone. Except for ActiveSupport (that gets a pass for being a framework) very few gems ship with monkey patch. A notable exception being "protocol" type of methods, such as `to_json`, `to_yaml`, `to_msgpack`, etc. In addition, I routinely use monkey patches to backport a fix onto a gem while waiting for a fix to be merged and published upstream. If monkey patches became scoped to namespaces, this would make this sort of "monkey patches" way harder. So to me it's net negative.
Being able to namespace existing code
Again not listed in your motivations, but you explain pretty well that you want to be able to load arbitrary code into a namespace, because you don't want to have to modify the existing libraries. It makes sense, but is it really that big of a need? I personally see namespaces as a feature libraries can use to write more robust and isolated code. Not as a feature applications can use to workaround libraries. ## Other issues ### Deduplication Assuming this implementation of namespaces become largely used, it means some versions of some libraries would be loaded dozens and dozens of time in the same process. IIRC in some previous public talks you mentioned the possibility of deduplication, what's the status on this? Because without it, it's a big concern to me. With Python/Java/Node namespacing systems it's an easily solved problem, because the file is essentially a namespace objects, so you can just keep a map of `file -> namespace_object`, but here it seems way more involved. ## What I think would be a positive In order to not just be negative, I'll try to explain what I think would be helpful. ### Local namespace A common complaint I hear from less experienced / occasional Ruby users is they are having trouble figuring out where constants are comming from, because of the single global namespace. They prefer the Java/Python/Node style, where each file is more or less its own namespace, and at the top of the file you list your imports. I think translated in Ruby, it could be emulated by only allowing to reference constants from outside the namespace in a fully qualified way: ```ruby class SomeClass end namespace MyLibrary p SomeClass # NameError SomeClass = ::SomeClass # This is basically an import p SomeClass # works end ``` In other word, I think namespaces could be somewhat similar to `BasicObject` but for modules. ## Overly public constants Another common issue I witnessed is publicly exposed constants, that aren't meant to be public. Being involved in a really big application, what people are trying to do to make that codebase more manageable is to break it down in smaller components with the hope that a developer can more easily wrap their head around a single component, that a component can be tested individually, etc. This often fall appart because all constants are public by default, so other teams end up relying on APIs that weren't meant to be used. I think it would be helpful if namespaces constants were private by default and you had to explictly "export" (publicize) them. ---------------------------------------- Feature #21311: Namespace on read (revised) https://bugs.ruby-lang.org/issues/21311#change-112916 * Author: tagomoris (Satoshi Tagomori) * Status: Open ---------------------------------------- This replaces #19744 ## Concept This proposes a new feature to define virtual top-level namespaces in Ruby. Those namespaces can require/load libraries (either .rb or native extension) separately from other namespaces. Dependencies of required/loaded libraries are also required/loaded in the namespace. This feature will be disabled by default at first, and will be enabled by an env variable `RUBY_NAMESPACE=1` as an experimental feature. (It could be enabled by default in the future possibly.) ### "on read" approach The "on write" approach here is the design to define namespaces on the loaded side. For example, Java packages are defined in the .java files and it is required to separate namespaces from each other. It can be implemented very easily, but it requires all libraries to be updated with the package declaration. (In my opinion, it's almost impossible in the Ruby ecosystem.) The "on read" approach is to create namespaces and then require/load applications and libraries in them. Programmers can control namespace separation at the "read" time. So, we can introduce the namespace separation incrementally. ## Motivation The "namespace on read" can solve the 2 problems below, and can make a path to solve another problem: * Avoiding name conflicts between libraries * Applications can require two different libraries safely which use the same module name. * Avoiding unexpected globally shared modules/objects * Applications can make an independent/unshared module instance. * Multiple versions of gems can be required * Application developers will have fewer version conflicts between gem dependencies if rubygems/bundler will support the namespace on read. (Support from RubyGems/Bundler and/or other packaging systems will be needed) For the motivation details, see [Feature #19744]. ## How we can use Namespace ```ruby # app1.rb PORT = 2048 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 2048 # app2.rb class Number def double = self * 2 end PORT = 2048.double class App def self.port = ::PORT def val = PORT.double.to_s end p App.port # 4096 # main.rb - executed as `ruby main.rb` ns1 = Namespace.new ns1.require('./app1') # 2048 ns2 = Namespace.new ns2.require('./app2') # 4096 PORT = 8080 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 8080 p App.new.val # "8080" p ns1::App.port # 2048 p ns1::App.new.val # "2048" p ns2::App.port # 4096 p ns2::App.new.val # "8192" 1.double # NoMethodError ``` ## Namespace specification ### Types of namespaces There are two namespace types, "root" and "user" namespace. "Root" namespace exists solely in a Ruby process, and "user" namespaces can be created as many as Ruby programmers want. ### Root namespace Root namespace is a unique namespace to be defined when a Ruby process starts. It only contains built-in classes/modules/constants, which are available without any `require` calls, including RubyGems itself (when `--disable-gems` is not specified). At here, "builtin" classes/modules are classes/modules accessible when users' script evaluation starts, without any require/load calls. ### User namespace User namespace is a namespace to run users' Ruby scripts. The "main" namespace is the namespace to run the user's `.rb` script specified by the `ruby` command-line argument. Other user namespaces ("optional" namespaces) can be created by `Namespace.new` call. In user namespace (both main and optional namespaces), built-in class/module definitions are copied from the root namespace, and other new classes/modules are defined in the namespace, separately from other (root/user) namespaces. The newly defined classes/modules are top-level classes/modules in the main namespace like `App`, but in optional namespaces, classes/modules are defined under the namespace (subclass of Module), like `ns::App`. In that namespace `ns`, `ns::App` is accessible as `App` (or `::App`). There is no way to access `App` in the main namespace from the code in the different namespace `ns`. ### Constants, class variables and global variables Constants, Class variables of built-in classes and global variables are also separated by namespace. Values set to class/global variables in a namespace are invisible in other namespaces. ### Methods and procs Methods defined in a namespace run with the defined namespace, even when called from other namespaces. Procs created in a namespace run with the defined namespace too. ### Dynamic link libraries Dynamic link libraries (typically .so files) are also loaded in namespaces as well as .rb files. ### Open class (Changes on built-in classes) In user namespaces, built-in class definitions can be modified. But those operations are processed as copy-on-write of class definition from the root namespace, and the changed definitions are visible only in the (user) namespace. Definitions in the root namespace are not modifiable from other namespaces. Methods defined in the root namespace run only with root-namespace definitions. ## Enabling Namespace Specify `RUBY_NAMESPACE=1` environment variable when starting Ruby processes. `1` is the only valid value here. Namespace feature can be enabled only when Ruby processes start. Setting `RUBY_NAMESPACE=1` after starting Ruby scripts performs nothing. ## Pull-request https://github.com/ruby/ruby/pull/13226 -- https://bugs.ruby-lang.org/