Project

General

Profile

Feature #12138

Support `Kernel#load_with_env(filename, cbase: SomeMod, cref: someMod, binding: SomeMod) # => obj`

Added by josh.cheek (Josh Cheek) about 1 year ago. Updated 6 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:74101]

Description

Ruby's require and load methods currently only return true, which means that any code being loaded must affect the global namespace, or have the global namespace affected for it to interact with.

This means that to load data, like a gemspec, you have to read the file in and eval it:
* Rubygems
* Bundler

To load a plugin or configuration, you have to modify a global object:
* [Railties](https://github.com/rails/rails/blob/e2f08a1c0a9d1dc2f27d1dfcd3c9937f4190554a/railties/lib/rails/engine.rb#L356-#L358) hook into subclassing
* RSpec tests have to be declared to a global object
* Minitest, too
* Rake extends main to store results on a [global object](https://github.com/ruby/rake/blob/7c9014e5559e846e9ffee1cf1584c4454374dd70/lib/rake/dsl_definition.rb#L58-#L60)

It's why gems have to be built the way they do, to avoid colliding with other code in the global namespace (fwiw, I've seen a computer segfault when the person unwittingly write their own Queue class). Which is also why we can't load multiple versions of a gem in the same namespace.

History

#1 [ruby-core:74129] Updated by shevegen (Robert A. Heiler) about 1 year ago

+1 for the spirit of the suggestion

Perhaps ruby 3.x will also feature some more advanced import-like system
fitting to ruby. :) Manipulating environments or objects-in-environments
would be nice.

I have no particular strong feeling in favour or disfavour of the syntax
but it seems a bit hard to remember, the
(filename, cbase: SomeMod, cref: someMod, binding: SomeMod)

#2 [ruby-core:74163] Updated by josh.cheek (Josh Cheek) about 1 year ago

Robert A. Heiler wrote:

+1 for the spirit of the suggestion

Perhaps ruby 3.x will also feature some more advanced import-like system
fitting to ruby. :) Manipulating environments or objects-in-environments
would be nice.

I have no particular strong feeling in favour or disfavour of the syntax
but it seems a bit hard to remember, the
(filename, cbase: SomeMod, cref: someMod, binding: SomeMod)

Aye, I have no preference either, I chose those names just to make it clear what things I want to be able to set. Ie RSpec.describe ... would be fine if I could choose what object RSpec evaluates to in that file. Or toplevel method defs would be fine if I could choose what object they get defined on. By giving it a binding to evaluate within, I can choose what its self should be, and provide it with local variables. I don't particularly care how this is achieved.

#3 [ruby-core:76412] Updated by matz (Yukihiro Matsumoto) 8 months ago

  • Status changed from Open to Feedback

I understand the need for load() with context, but this proposal has

  • a bad name, "env" is ambiguous
  • the proposed context (cbase, cref, binding) is not proven sufficient

So you (or someone) have to improve the proposal.

Matz.

#4 [ruby-core:77457] Updated by josh.cheek (Josh Cheek) 6 months ago

Yukihiro Matsumoto wrote:

I understand the need for load() with context, but this proposal has

  • a bad name, "env" is ambiguous
  • the proposed context (cbase, cref, binding) is not proven sufficient

So you (or someone) have to improve the proposal.

Matz.

I don't understand what "proven sufficient" entails. Is there a metric I could use to know it was achieved?

Also available in: Atom PDF