ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: duerst <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:109955] [Ruby master Feature#10320] require into module
Date: Mon, 19 Sep 2022 08:25:22 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-99206.20220919082522.7501@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-10320.20141002224417.7501@ruby-lang.org

Issue #10320 has been updated by duerst (Martin Dürst).


shyouhei (Shyouhei Urabe) wrote in #note-21:
> May I ask someone the problem this ticket is currently trying to address? I’m confused.

Same question here.

My (I hope average Ruby progarmmer) understanding of how gems/modules/namespaces are supposed to work currently is as follows (overview):
- Each gem uses a (top) module, where the module name is (modulo some case/... changes) the same as the gem name.
- Each gem puts its constants (which included classes and modules) into that gem's (top) module.
- rubygems.org makes sure that each gem name can only be used for one gem, and thus module names used by different gems are different.

The above is mostly a social contract on how to use modules in gems, but my understanding is that it is widely understood and followed. I'm sure there are exceptions, but I'd guess they happen mostly in toy "gems" written by beginners.

My guess at reasons for this proposal are the following (but I would of course like to know the real reasons):
1) Namespaces are a precious resource, and the less we sit on it, the better, even if practically, there may not be much of a problem.
2) Some people are used to how modules work in JavaScript, and want the same in Ruby.
3) Different modules may require the same modules but e.g. with different versions. (I didn't find any discussion of versions above, however, and the discussion of "using the same module by aliasing when it's included more than once" seems to indicate that different versions are not relevant here. Also, versioning is mostly bundler's job.
4) Companies (but not only companies) using Ruby have internal libraries with modules. They don't want to squat on a gem name (doing so may reveal company internals including business plans), but they don't want to risk a future name conflict.

The above are only guesses. There may by more than one reason. But I think we should make it/them as explicit as possible.

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

* 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-19  8:25 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 ` duerst [this message]
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 ` [ruby-core:109973] " mame (Yusuke Endoh)
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-99206.20220919082522.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).