[ruby-core:109955] [Ruby master Feature#10320] require into module
From:
duerst <noreply@...>
Date:
2022-09-19 08:25:22 UTC
List:
ruby-core #109955
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窶冦 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 ツequire '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/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>