Issue #19990 has been updated by rubyFeedback (robert heiler). Just two short things: 1) I believe it should be assessed whether this proposed change may affect existing gems and ruby devs, e. g. how many make use of this feature. Personally it would not affect me as I do not use it, but it may affect others, so that should be included in the suggestion as a potential trade-off (e. g. folks having to modify their code). 2) fxn wrote:

So, the documentation should say:

"It kind of protects, but not really"

I think this change would be problematic too, because other ruby users could wonder what this means, e. g. "it kind of protects, but not really". This would be confusing to some people and I don't think this is a good change to the documentation. It would kind of be similar to this as an extreme example: "Flowers are plants, but not really." So the documentation should not be internally inconsistent here. ---------------------------------------- Bug #19990: Could we reconsider the second argument to Kernel#load? https://bugs.ruby-lang.org/issues/19990#change-105185 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The documentation of `Kernel#load` says:

If the optional wrap parameter is true, the loaded script will be executed under an anonymous module, protecting the calling program’s global namespace. If the optional wrap parameter is a module, the loaded script will be executed under the given module. In no circumstance will any local variables in the loaded file be propagated to the loading environment.

I'd like to ask you to reconsider this feature. First of all, "protecting the calling program" is not really accomplished because the loaded file may still do this ```ruby class ::C # defines ::C regardless of the second argument end ``` Another example, if the caller defines a module `M`, then the loaded program can also define things in `M`: ```ruby class M::C # defines ::M::C regardless of the second argument end ``` It does not even need a leading `::`. So, the "protection" is not really there. In addition to that, this is not transparent for the code being loaded either. For example, let's take this program: ```ruby class A end module X ::A # could be needed if your own lookup had an A somewhere you want to skip end ``` the Ruby programmer expects that to work. But with this feature, on paper, nobody knows if it wil work. How can you ship code confidently? So, the documentation should say:

It kind of protects, but not really. Also, the loaded file may not work as expected, or may not even be loadable at all.

That hypothetical documentation suggests to me it would be worth revisiting this feature. In Ruby, as it is today, things are global. The language does not have features to really isolate code as containers do, for example. I believe the 2nd argument to `Kernel#load` steers the API in a direction that is not consistent with the language, and provides a feature that is only partial and cannot satisfy what it promises. I'd be in favor of deprecating and eventually removing this API. -- https://bugs.ruby-lang.org/

Issue #19990 has been updated by jeremyevans0 (Jeremy Evans). @fxn is correct that module wrapping offers no protection. We should remove the "protecting the calling program’s global namespace" part. However, the other parts of the documentation are accurate. Just because you are wrapping code in a module doesn't protect the code: ```ruby module M class ::C; end class A::B; end end ``` @fxn, assuming we remove the part related to protection, do you still believe we need to add other remarks? It seems to me we do not have any issues if we remove the part about protection, because the part about module wrapping seems easy to understand. ---------------------------------------- Bug #19990: Could we reconsider the second argument to Kernel#load? https://bugs.ruby-lang.org/issues/19990#change-105192 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The documentation of `Kernel#load` says:

If the optional wrap parameter is true, the loaded script will be executed under an anonymous module, protecting the calling program’s global namespace. If the optional wrap parameter is a module, the loaded script will be executed under the given module. In no circumstance will any local variables in the loaded file be propagated to the loading environment.

I'd like to ask you to reconsider this feature. First of all, "protecting the calling program" is not really accomplished because the loaded file may still do this ```ruby class ::C # defines ::C regardless of the second argument end ``` Another example, if the caller defines a module `M`, then the loaded program can also define things in `M`: ```ruby class M::C # defines ::M::C regardless of the second argument end ``` It does not even need a leading `::`. So, the "protection" is not really there. In addition to that, this is not transparent for the code being loaded either. For example, let's take this program: ```ruby class A end module X ::A # could be needed if your own lookup had an A somewhere you want to skip end ``` the Ruby programmer expects that to work. But with this feature, on paper, nobody knows if it wil work. How can you ship code confidently? So, the documentation should say:

It kind of protects, but not really. Also, the loaded file may not work as expected, or may not even be loadable at all.

That hypothetical documentation suggests to me it would be worth revisiting this feature. In Ruby, as it is today, things are global. The language does not have features to really isolate code as containers do, for example. I believe the 2nd argument to `Kernel#load` steers the API in a direction that is not consistent with the language, and provides a feature that is only partial and cannot satisfy what it promises. I'd be in favor of deprecating and eventually removing this API. -- https://bugs.ruby-lang.org/

Issue #19990 has been updated by fxn (Xavier Noria). Let me add that example with `::A` is just _one_ way to illustrate lack of transparency. There are many others, for example: ```ruby class String # expected to reopen ::String def foo end end "".foo # expected to work ``` That program works normally, but raises `NoMethodError` if loaded with `load program, true`. Bottom line is, the moment you unilaterally change the nesting to the loaded file, all kind of unexpected things may happen because the assumptions of the programmer of that file do not hold anymore (unless there is coordination). This cannot be transparent. It is just a matter of looking for the consequences of loosing your control over the nesting. ---------------------------------------- Bug #19990: Could we reconsider the second argument to Kernel#load? https://bugs.ruby-lang.org/issues/19990#change-105195 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The documentation of `Kernel#load` says:

If the optional wrap parameter is true, the loaded script will be executed under an anonymous module, protecting the calling program’s global namespace. If the optional wrap parameter is a module, the loaded script will be executed under the given module. In no circumstance will any local variables in the loaded file be propagated to the loading environment.

I'd like to ask you to reconsider this feature. First of all, "protecting the calling program" is not really accomplished because the loaded file may still do this ```ruby class ::C # defines ::C regardless of the second argument end ``` Another example, if the caller defines a module `M`, then the loaded program can also define things in `M`: ```ruby class M::C # defines ::M::C regardless of the second argument end ``` It does not even need a leading `::`. So, the "protection" is not really there. In addition to that, this is not transparent for the code being loaded either. For example, let's take this program: ```ruby class A end module X ::A # could be needed if your own lookup had an A somewhere you want to skip end ``` the Ruby programmer expects that to work. But with this feature, on paper, nobody knows if it wil work. How can you ship code confidently? So, the documentation should say:

It kind of protects, but not really. Also, the loaded file may not work as expected, or may not even be loadable at all.

That hypothetical documentation suggests to me it would be worth revisiting this feature. In Ruby, as it is today, things are global. The language does not have features to really isolate code as containers do, for example. I believe the 2nd argument to `Kernel#load` steers the API in a direction that is not consistent with the language, and provides a feature that is only partial and cannot satisfy what it promises. I'd be in favor of deprecating and eventually removing this API. -- https://bugs.ruby-lang.org/

Issue #19990 has been updated by kjtsanaktsidis (KJ Tsanaktsidis). Because of the reasons you identify, `Kernel#load` is absolutely not some kind of general module containerisation feature (of the kind perhaps envisaged by https://bugs.ruby-lang.org/issues/19744). But I think it does have a _limited_ use-case for loading _particular_ scripts which are known to pollute the global namespace by accident in an undesirable way. Although as I write this, I realise Ruby already has this functionality: ```ruby irb(main):001> File.read('broken_script.rb') => "X = 8\n" irb(main):002> broken_toplevel_binding = Module.new.tap { _1.class_eval File.read('broken_script.rb') } => #<Module:0x00000001048bdf30> irb(main):003> X (irb):3:in `<main>': uninitialized constant X (NameError) from /Users/ktsanaktsidis/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/irb-1.8.3/exe/irb:9:in `<top (required)>' from /Users/ktsanaktsidis/.rbenv/versions/3.2.2/bin/irb:25:in `load' from /Users/ktsanaktsidis/.rbenv/versions/3.2.2/bin/irb:25:in `<main>' irb(main):004> broken_toplevel_binding::X => 8 ``` Since `Kernel#load` can subtly do the wrong thing on some files that are loaded, and since it's possible to obtain that behaviour explicitly in the cases where it really is desirable, I think deprecating it makes sense. ---------------------------------------- Bug #19990: Could we reconsider the second argument to Kernel#load? https://bugs.ruby-lang.org/issues/19990#change-105205 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The documentation of `Kernel#load` says:

If the optional wrap parameter is true, the loaded script will be executed under an anonymous module, protecting the calling program’s global namespace. If the optional wrap parameter is a module, the loaded script will be executed under the given module. In no circumstance will any local variables in the loaded file be propagated to the loading environment.

I'd like to ask you to reconsider this feature. First of all, "protecting the calling program" is not really accomplished because the loaded file may still do this ```ruby class ::C # defines ::C regardless of the second argument end ``` Another example, if the caller defines a module `M`, then the loaded program can also define things in `M`: ```ruby class M::C # defines ::M::C regardless of the second argument end ``` It does not even need a leading `::`. So, the "protection" is not really there. In addition to that, this is not transparent for the code being loaded either. For example, let's take this program: ```ruby class A end module X ::A # could be needed if your own lookup had an A somewhere you want to skip end ``` the Ruby programmer expects that to work. But with this feature, on paper, nobody knows if it wil work. How can you ship code confidently? So, the documentation should say:

It kind of protects, but not really. Also, the loaded file may not work as expected, or may not even be loadable at all.

That hypothetical documentation suggests to me it would be worth revisiting this feature. In Ruby, as it is today, things are global. The language does not have features to really isolate code as containers do, for example. I believe the 2nd argument to `Kernel#load` steers the API in a direction that is not consistent with the language, and provides a feature that is only partial and cannot satisfy what it promises. I'd be in favor of deprecating and eventually removing this API. -- https://bugs.ruby-lang.org/