ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "mame (Yusuke Endoh)" <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:109973] [Ruby master Feature#10320] require into module
Date: Wed, 21 Sep 2022 09:46:38 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-99223.20220921094637.7501@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-10320.20141002224417.7501@ruby-lang.org

Issue #10320 has been updated by mame (Yusuke Endoh).


The proposed PR is simple, small, and appears to have few performance or compatibility issues. So I am basically positive about this proposal.

> The main goal is to avoid accidental dependency.

I guess that the ultimate goal is to modularize the monolith to microservices, and that this proposal is for the intermediate stage (i.e., to modularize the monolith in a process). Am I right? It is not so obvious to me that this intermediate step would be useful, maybe because I don't have enough experience in monolith development :-)

> Resolve top-level references (::Foo) when loaded with wrap to the top of the module namespace, rather than the "absolute" top. For now I've done this in the gem using const_missing, but I intend on moving this to the Ruby patch.

This approach looks not very robust. If there is a constant `Foo` defined in the top-level, I think it does not work.

```
# foo.rb
A = :foo

p ::A
```

```
# main.rb
A = :main

load "foo.rb", Module.new #=> expect: :foo, Im hack: :main
```

More dedicated support in the Ruby core side would be necessary, I think. But I am curious about how much the change brings performance degeneration.

----------------------------------------
Feature #10320: require into module
https://bugs.ruby-lang.org/issues/10320#change-99223

* Author: sowieso (So Wieso)
* Status: Open
* Priority: Normal
----------------------------------------
When requiring a library, global namespace always gets polluted, at least with one module name. So when requiring a gem with many dependencies, at least one constant enters global namespace per dependency, which can easily get out of hand (especially when gems are not enclosed in a module).

Would it be possible to extend require (and load, require_relative) to put all content into a custom module and not into global namespace?

Syntax ideas:

~~~ruby
require 'libfile', into: :Lib   # keyword-argument
require 'libfile' in Lib   # with keyword, also defining a module Lib at current binding (unless defined? Lib)
require_qualified 'libfile', :Lib
~~~

This would also make including code into libraries much easier, as it is well scoped.

~~~ruby
module MyGem
  require 'needed' in Need

  def do_something
    Need::important.process!
  end
end
 # library user is never concerned over needed's content
~~~

Some problems to discuss:

* requiring into two different modules means loading the file twice?
* monkeypatching libraries should only affect the module ­→ auto refinements?
* maybe also allow a binding as argument, not only a module?
* privately require, so that required constants and methods are not accessible from the outside of a module (seems to difficult)
* what about $global constants, read them from global scope but copy-write them only to local scope?

Similar issue:
https://bugs.ruby-lang.org/issues/5643



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

  parent reply	other threads:[~2022-09-21  9:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-10320.20141002224417.7501@ruby-lang.org>
2021-06-10  5:51 ` [ruby-core:104226] [Ruby master Feature#10320] require into module j.ruby-lang
2021-06-10  6:18 ` [ruby-core:104227] " branzeanu.aurel
2021-06-10  8:15 ` [ruby-core:104228] " j.ruby-lang
2022-09-15  3:19 ` [ruby-core:109898] " shioyama (Chris Salzberg)
2022-09-16  6:52 ` [ruby-core:109915] " Eregon (Benoit Daloze)
2022-09-16  7:34 ` [ruby-core:109916] " shyouhei (Shyouhei Urabe)
2022-09-16 10:52 ` [ruby-core:109918] " nobu (Nobuyoshi Nakada)
2022-09-16 21:45 ` [ruby-core:109923] " byroot (Jean Boussier)
2022-09-17  1:53 ` [ruby-core:109925] " shioyama (Chris Salzberg)
2022-09-17  2:00 ` [ruby-core:109926] " shioyama (Chris Salzberg)
2022-09-17  2:32 ` [ruby-core:109927] " shioyama (Chris Salzberg)
2022-09-18 10:43 ` [ruby-core:109946] " shyouhei (Shyouhei Urabe)
2022-09-19  8:25 ` [ruby-core:109955] " duerst
2022-09-19  8:32 ` [ruby-core:109956] " byroot (Jean Boussier)
2022-09-19 17:23 ` [ruby-core:109959] " vo.x (Vit Ondruch)
2022-09-20 10:58 ` [ruby-core:109960] " retro
2022-09-21  9:46 ` mame (Yusuke Endoh) [this message]
2022-09-21 10:26 ` [ruby-core:109974] " byroot (Jean Boussier)
2022-09-21 12:39 ` [ruby-core:109979] " shioyama (Chris Salzberg)
2022-09-21 17:08 ` [ruby-core:109981] " mame (Yusuke Endoh)
2022-09-21 18:11 ` [ruby-core:109982] " jeremyevans0 (Jeremy Evans)
2022-09-25 12:54 ` [ruby-core:110071] " shioyama (Chris Salzberg)
2022-09-27  0:54 ` [ruby-core:110098] " shioyama (Chris Salzberg)

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-99223.20220921094637.7501@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).