From: jjyruby@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:88462] [Ruby trunk Feature#14982] Improve namespace system in ruby to avoiding top-level names chaos
Date: Mon, 13 Aug 2018 07:05:36 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-73528.20180813070535.1d0e3d43a96eb1ad@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-14982.20180811042606@ruby-lang.org
Issue #14982 has been updated by jjyr (Jinyang Jiang).
I can imagine how hard to implement the "requiring into isolated binding" correct in VM.
If we want to maintain the compatible we need to maintain the reference of the name cross different require/import.
Think of a situation:
```ruby
# foo.rb
class Foo
@count = 0
def self.count
@count += 1
end
end
# another_file.rb
namespace do
import :Foo, from: 'foo'
Foo.count # should return 1
end
require 'foo', into: :FooSpace
FooSpace::Foo.count # should return 2
# require 'foo'
Foo.count # should return 3
```
The name Foo from path 'foo' should always be the same reference whether how the name imported.
And imaging in case we have path 'foo/bar' and 'foo' require 'foo/bar', the name from 'foo/bar' should also be the same reference across files.
----------
It's mean each time we require or require into a file, we put it in a Binding associated with the file path. (so we can think the requiring in ruby VM is like to find a file and Binding by absolute path)
In VM level, we may also need to implement a nested Binding structure to support this feature: find a name from each required bindings. (like examples above, RubyVm howto lookup the name Foo?)
So it is hard to support this feature, and maybe cause VM performance issue on name lookup.
----------------------------------------
Feature #14982: Improve namespace system in ruby to avoiding top-level names chaos
https://bugs.ruby-lang.org/issues/14982#change-73528
* 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/
next prev parent reply other threads:[~2018-08-13 7:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-14982.20180811042606@ruby-lang.org>
2018-08-11 4:26 ` [ruby-core:88446] [Ruby trunk Feature#14982] Introduce new namespace system to ruby to avoiding top-level names chaos jjyruby
2018-08-11 12:41 ` [ruby-core:88449] [Ruby trunk Feature#14982] Improve namespace system in " shevegen
2018-08-12 9:12 ` [ruby-core:88454] " jjyruby
2018-08-13 1:12 ` [ruby-core:88458] " shyouhei
2018-08-13 3:34 ` [ruby-core:88459] " merch-redmine
2018-08-13 6:40 ` [ruby-core:88461] " jjyruby
2018-08-13 7:05 ` jjyruby [this message]
2018-08-16 21:02 ` [ruby-core:88506] " jjyruby
2018-08-23 7:25 ` [ruby-core:88612] " ko1
2018-09-12 7:48 ` [ruby-core:88957] " loic.nageleisen
2018-11-22 15:04 ` [ruby-core:89974] " ciconia
2018-11-23 13:38 ` [ruby-core:90006] " v.ondruch
2018-11-23 14:26 ` [ruby-core:90007] " ciconia
2018-11-24 17:04 ` [ruby-core:90041] " v.ondruch
2018-11-24 20:35 ` [ruby-core:90048] " eregontp
2018-11-24 21:05 ` [ruby-core:90050] " v.ondruch
2018-11-24 21:09 ` [ruby-core:90051] " v.ondruch
2018-11-24 21:40 ` [ruby-core:90052] " ciconia
2019-03-23 1:10 ` [ruby-core:91953] " chocolate
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-73528.20180813070535.1d0e3d43a96eb1ad@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).