Feature #21365: Add `Namespace#eval`

• Status: Open
• Assignee: -
• Target version: -

[tenderlovemaking (Aaron Patterson)]

I would like a way to eval code on to a Namespace object. Could we add an eval method that doesn't take a binding object? Writing a new file every time I want to test Namespaces is too cumbersome.

Thanks!

[matheusrich (Matheus Richard)]

I'm curious why eval and not instance_eval?

[Eregon (Benoit Daloze)]

Yep, agreed it'd be far more convenient for testing Namespace.

matheusrich (Matheus Richard) wrote in #note-1:

I'm curious why eval and not instance_eval?

Why instance_eval? The distinction between eval/class_eval/instance_eval does not seem relevant here.

Though of course the semantics should be the same as writing the code to a file + Namespace#require so e.g. ns.eval "def foo = 42" defines method foo on ns' copy of Object methods.

[matheusrich (Matheus Richard)]

@Eregon (Benoit Daloze) I feel like that's more consistent with the rest of the language. I can't remember if any object as a eval method. But evaluating some code in a particular instance context makes me think of instance_eval.

[ufuk (Ufuk Kayserilioglu)]

matheusrich (Matheus Richard) wrote in #note-3:

@Eregon (Benoit Daloze) I feel like that's more consistent with the rest of the language. I can't remember if any object as a eval method. But evaluating some code in a particular instance context makes me think of instance_eval.

I am not sure I understand. All objects have an eval method in the form of Kernel#eval: https://ruby-doc.org/3.4.1/Kernel.html#method-i-eval

[matheusrich (Matheus Richard)]

@ufuk (Ufuk Kayserilioglu) fair point. Although it is a private method, so we're never doing "foo".eval(bar).

[Eregon (Benoit Daloze)]

ns.eval "self" would be the Namespace "main" object, not the Namespace instance itself, so instance_eval would be a bad fit here.

AFAIK, instance_eval is only called as such because any def foo; end inside it will definite a singleton method on the instance.
And similarly class_eval defines def foo; end as a class instance method.
This is not relevant here, def foo; end would have normal top-level def semantics (in that namespace).

[fxn (Xavier Noria)]

instance_eval modifies the nesting in the eval'ed code. Since namespaces are modules, instance_eval already works:

ns = Namespace.new
ns.instance_eval "p Module.nesting"

That prints [Namespace].

I believe @tenderlovemaking (Aaron Patterson) wants a regular top-level execution context, where the nesting would be empty, in particular (mod https://bugs.ruby-lang.org/issues/21318).

[matheusrich (Matheus Richard)]

Thanks for the clarification, everyone!

[fxn (Xavier Noria)]

I want to clarify that I explained that instance_eval works, and what it does, because Namespace is a Module.

But that does not mean I believe that is good.

Namespaces try to be one thing, but by being modules they carry other things that, in my view, are not quite coherent with the feature.

It is another instance of my hunch that namespaces should be a new entity with new rules.

In this particular case, I believe they should not respond to instance_eval, or module_eval or anything. Precisely, the proposed eval in this ticket is what makes sense to me: "run this code in your execution context".