ruby-core

Issue #10320 has been updated by jeremyevans0 (Jeremy Evans).


I think that trying to require into a module with code that was not designed for it will break things.  One example is when using absolute constant references (those that start with `::`).  Consider this code:

```ruby
class A; end

class B < BasicObject
  C = ::Object
  D = ::A
end
```

This is an example of where you would generally use absolute constant references, because constant lookup in `BasicObject` will not look up constants in `Object`/top-level.  However, any case where you are using absolute constant references should have this issue.

How would the code above work when loaded into a module?  If absolute constant references are resolved through the module, the access to `::Object` breaks, since that is not defined in the module.  If absolute constant references are not resolved through the module, the access to `::A` breaks, since it would no longer be defined at `Object`/top-level.  Looking in the module first and then `Object`/top-level (or vice-versa) feels ad-hoc, and either approach has corner cases where it breaks.

It looks like `Im` attempts to handle the above case by copying global constants into the module.  I doubt we would want to do that in `load` or `require`.

shioyama (Chris Salzberg) wrote in #note-19:
> > This NilClass definition, even if reassigning global ::NilClass doesn't have any effect on nil though, isn't it?
> Or do you actually define mod::NilClass = NilClass before loading the ActiveSupport files?
> 
> Yes, `mod::NilClass = NilClass` is assigned in the module before passing it to the first `load`, so when loading core extensions ActiveSupport sees `mod::NilClass` and this simply points to `::NilClass`.
> 
> You can confirm it works:
> 
> ```ruby
> nil.blank?
> #  undefined method `blank?' for nil:NilClass (NoMethodError)
> 
> require "im"
> extend Im
> 
> mod = import "active_support"
> #=> <#Im::Import root: active_support>
> 
> ActiveSupport
> # `const_missing': uninitialized constant ActiveSupport (NameError)
> 
> mod::ActiveSupport
> #=> ActiveSupport
> 
> nil.blank?
> #=> true
> ```

To me, this example is a perfect indication of why we shouldn't support this.  This uses `import` to load `ActiveSupport`, so that `ActiveSupport` is not added to top level namespace, but all of the core extensions added by `ActiveSupport` are still active. The namespace isolation is only partial, it is not complete.

There is discussion about how this could allow multiple versions of the same gem versions to work.  How would that work if the gem makes modifications to core classes, as `ActiveSupport` does?  Let's say you are including/prepending a module in the class in both versions, overriding a method, and and calling `super` for default behavior.  Seems like you would get the behavior for both versions, which is unlikely to be desirable.  The situation is worse if a method aliasing approach is used, since running `alias orig_method method; def method; code; orig_method; end` twice would likely result in a method that causes `SystemStackError`.

I'm against `require` accepting a module similar to load, and against making the module wrapping behavior transitive, so that `require` and `load` automatically use the currently wrapping module.

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

* 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/

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

Thread

Prev Next

In This Thread

Prev Next