Project

General

Profile

Actions

Feature #12138

closed

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

Added by josh.cheek (Josh Cheek) about 8 years ago. Updated over 7 years ago.

Status:
Feedback
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:

To load a plugin or configuration, you have to modify a global object:

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.

Updated by shevegen (Robert A. Heiler) about 8 years 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)

Updated by josh.cheek (Josh Cheek) about 8 years 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.

Updated by matz (Yukihiro Matsumoto) over 7 years 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.

Updated by josh.cheek (Josh Cheek) over 7 years 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?

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0