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:
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.
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)
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 
Updated by 
Updated by