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

Issue #14982 has been updated by shevegen (Robert A. Heiler).


I think this has come up before in other issue requests.

I also had a few ideas; e. g. to be able to attach meta-information
to class/modules (that way we can find out who is the original author,
when and what changes may have been made etc...).

I agree with this comment here a lot by the way:

    import :"A::B::C::D", as: :E

Not necessarily about using the name "import", but with the ability
to re-define namespaces at require time. We can of course already
do so by including modules and removing (older) constants, but I 
always thought it may be more elegant to be able to do so the moment
we require ruby code.

I am not so sure about the rest of the suggestion. I don't have any
particularly strong pro or con opinion, although I am a bit wary.

Part of the suggestions all are a bit complicated, API-wise and from
the scope. I understand that, if we want more flexibility, we may 
need to be able to have a way to add code which requires more characters
and such. But one thing that is great in ruby, even if we say that 
"having no namespaces is a disadvantage", is that using modules and
classes on the toplevel space, is very, very simple. People very
quickly understand that concept.

    class Cat
      def meow
        puts 'The cat meows.'
      end
    end

With namespaces as suggested here, we may add another layer of 
complexity; and while I do agree with some stronger form of
control possible over "namespaces" in ruby, I am not sure if
the proposal in this form is having a good trade-off. But as I
wrote, it's not that I have a big opinion either way - I think
the biggest concern I have had in regards to namespaces was
when ruby were to use PHP's "solution" and syntax for 
namespaces ... :P

As for refinements - the odd thing is that I agree behind the
proposal and ideas, but the syntax and API is so weird to me
and it feels ... strange to use them. I also have no alternative
suggestion, so this is not good; best way would be to have
both namespaces, namespace scopes and refinements in a single
issue with a great, beautiful syntax. :D

(We should however had also consider whether the status quo
is actually better than the proposed changes. And to some
extent I'd rather use a status quo than want to transition
into changes that do not seem to be as worthwhile to be
had - even though I actually agree with a LOT on what is 
said about namespaces, refinements etc...)

- As for requiring ruby code, I agree. In particular for larger
projects written in ruby, it may be useful to not only have
more control, but make managing that ruby code simpler. In
your example, the author who wrote the code must have forgotten
to require some other files; but I understand that this may
be tedious if one has a large project with lots of .rb files.
Then there are also circular warnings which are no fun at all.

I am confident that this may improve in the long run - matz 
always said that ruby is for humans rather than computers
and that the core team will listen to (and prioritize on)
"real problems" and painpoints people have when writing
ruby code. And personally I think that a lot of these problems
emerge when one writes a lot of ruby code and has lots of 
ruby files, too. 

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

* Author: jjyr (jy j)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
## 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/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>