[ruby-core:88459] [Ruby trunk Feature#14982] Improve namespace system in ruby to avoiding top-level names chaos

[merch-redmine@jeremyevans.net]

Issue #14982 has been updated by jeremyevans0 (Jeremy Evans).


In the Why? section, case 1 is just a programming error on the library developer's or library user's part, depending on how the library is documented.  

In terms of case 2 (multiple gems define overlapping constants in the top level namespace), that could be a issue in theory, but it doesn't generally present a problem in practice as library authors in most cases take care to choose non-overlapping names.

It will probably be challenging to make `import` work with ruby's constant lookup if the top level namespace is not actually modified.  Libraries may expect that their constants names are available in the top level namespace:

~~~ ruby
# foo_a.rb
class Foo
  def self.foo
    ::Foo
    # or Foo
    # or Object.const_get(:Foo)
  end
end

# foo_b.rb
class Foo
  def self.foo
    ::Foo
  end
end

# main
namespace :Bar do
  import :Foo, as: :Foo_A, from: 'foo_a'
  import :Foo, as: :Foo_B, from: 'foo_b'

  Foo_A.foo
  Foo_B.foo
end
~~~

I suppose it is possible, but CREF handling in the VM would have to be made significantly more complex to implement it correctly (so that the code works the same both via `require` and `import :as`).


You can sort of get what you want in terms of an isolated namespace with BasicObject subclasses:

~~~ ruby
class Foo
end

class Hello < BasicObject
end

class Hello
  Foo # NameError
end

Hello::Foo = ::Foo

class Hello
  Foo # no NameError
end

module A
  module B
    module C
      module D
      end
    end
  end
end

Hello::E = ::A::B::C::D

def Foo.foo; 1; end
Object.send(:remove_const, :Foo)

require 'foo_a'
# in foo_a.rb
# class Foo; end
# def Foo.foo; 2; end
Hello::Foo_A = Object.send(:remove_const, :Foo)

require 'foo_b'
# in foo_b.rb
# class Foo; end
# def Foo.foo; 3; end
Hello::Foo_B = Object.send(:remove_const, :Foo)

class Hello
  class Bar
    def xxx
      [Foo, Foo_A, Foo_B].map{|s| [s, s.foo]}
    end
  end
end

Hello::Bar.new.xxx
# [[Foo, 1], [Foo, 2], [Foo, 3]]
~~~

Such an approach certainly has it's own issues, though. Also, it doesn't really address the issue of trying to handle overlapping top level constants in separate libraries.

I see the benefits of this proposal, as require into isolated binding is a nice to have assuming everything continues to work. However, I don't think the benefits of this proposal would exceed the implementation and maintenance cost.

----------------------------------------
Feature #14982: Improve namespace system in ruby to avoiding top-level  names chaos
https://bugs.ruby-lang.org/issues/14982#change-73526

* Author: jjyr (Jinyang Jiang)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
Updated: https://bugs.ruby-lang.org/issues/14982#note-5



## Why

Ruby has evaluation all class/module names in top-level context(aka TOPLEVEL_BINDING). 
As a user we basically hard to know how many names in the current context, is causing chaos in some cases. For example:

case 1: 

Put common used errors class in a single file, like below

``` ruby
# utils/errors.rb

class FooError
end

class BarError
end
```

In other files under 'utils' we want to use those errors, so the best practice is to use `require_relative 'errors'` in each file we need.

``` ruby
# utils/binary_helper.rb

# we forget require errors

module BinaryHelper
# ...
  raise BarError
# ...
end

```

But sometime we may forget to require dependencies in a file, it's hard to notice because
 if RubyVM already execute the requires we still can access the name BarError,

but if user directly to require 'utils/binary_helper', he/she will got an NameError.


case 2: 

Two gems use same top-level module name, so we can't use them together

## The Reason of The Problem

The reason is we let module author to decision which module user can use. ('require' is basically evaluation, highly dependent on the module author's design)

But we should let users control which names to use and available in context. As many other popular languages dose(Rust, Python..)

I think the solution is basically the same philosophy compares to refinement feature.


## The Design

I propose an improved namespace to Ruby, to solve the problems and still compatible with the current Ruby module system.

``` ruby
class Foo
end

# introduce Kernel#namespace
namespace :Hello do
  # avoiding namespace chaos
  # Foo -> NameError, can't access TOPLEVEL_BINDING directly
  
  # Kernel#import method, introduce Foo name from TOPLEVEL_BINDING
  import :Foo

  # in a namespace user can only access imported name
  Foo

  # import constant to another alias name
  # can avoid writing nested module/class names
  import :"A::B::C::D", as: :E

  # require then import, for convenient 
  import :"A::B::C::D", as: :E, from: 'some_rb_file'

  # import same name from two gems
  import :"Foo", as: :Foo_A, from: 'foo_a'
  import :"Foo", as: :Foo_B, from: 'foo_b'

  # import names in batch
  import %i{"A::B::C::D", "AnotherClass"}, from: 'some_rb_file'

  # import and alias in batch
  import {:"A::B::C::D" => :E, :Foo => Foo2}, from: 'some_rb_file'

  class Bar
    def xxx
      # can access all names in namespace scope
      [Foo, Foo_A, Foo_B]
    end
  end
end

Hello.class #  -> module. namespace is just a module
Hello::Bar # so we do not broken current ruby module design

# namespace system is intent to let user to control names in context
# So user can choose use the old require way

require 'hello'

Hello::Bar


# Or user can use namespace system as we do in hello.rb

namespace :Example do
  import :"Hello::Bar", as: :Bar
  Bar # ok
  Foo # name error, cause we do not import Foo in :Example namespace
end

Foo # ok, cause Foo is loaded in TOPLEVEL_BINDING

# define nested namespace

# more clear syntax than “module Example::NestedExample”
namespace :NestedExample, under: Example do
end

namespace :Example2 do
  namespace :NestedExample do
  end
end

```

Pros:

* Completely compatible with the current module system, a gem user can completely ignore whether a gem is write in Namespace or not.
* User can completely control which names in current context/scope.
* May solve the top module name conflict issue(depends on VM implementation).
* Avoid introducing new keyword and syntax.
* Type hint or name hint can be more accuracy under namespace(not sure).

Cons:

* Need to modify Ruby VM to support the feature.




-- 
https://bugs.ruby-lang.org/