In Ruby, what can eval(code, some_binding) read, and why can't later code in your method use a local the string assigned?

## What Kernel#eval does `Kernel#eval(string, binding = nil, filename = nil, lineno = nil)` compiles the string as Ruby code at run time and runs it. The second argument decides **where** the code runs: - **No binding**: the code runs in the caller's own scope. It sees the caller's `self`, the caller's local variables and the caller's constant lookup. - **A `Binding`**: the code runs in the scope where that binding was captured, typically by calling `binding` inside a method or block. It sees *that* scope's `self`, locals and constants, even if the method that created the binding has long returned. The `Binding` object itself — how it is captured and what it keeps alive — is a closures topic. For `eval` the point is simply that it names a scope. ## Reading through a binding A binding is how template engines and consoles let text refer to variables that exist somewhere else. If a method assigns `price = 40` and returns `binding`, then `eval("price * 2", that_binding)` returns `80`, and `eval("self", that_binding)` returns the object the method ran on. Calling `binding.eval("price * 2")` does the same thing: `Binding#eval` forwards to `Kernel#eval` with itself as the scope. ## Why new locals do not leak out Ruby decides which bare names are local variables **when it parses** a method, not when it runs it. A name counts as a local only if an assignment to it appears earlier in the same scope. So in: ```ruby def total eval("tax = 8") tax end ``` the parser never saw `tax = ...` in the method body — it was hidden inside a string — so the final `tax` is compiled as a method call. At run time it raises `NameError` (undefined local variable or method). The assignment inside the string did create a local, but in a scope that exists only for the evaluated code. With an explicit binding, the rules are: 1. A local created by `eval("tax = 8", b)` is stored in the binding's dynamic scope. 2. A later `eval("tax", b)` **on the same `Binding` object** finds it. 3. Compiled code around the call still does not see it, for the parsing reason above. 4. Two `eval` calls **without** a binding do not share new locals: `eval("z = 1"); eval("z")` raises `NameError`. | Code | Result | |---|---| | `eval("price * 2", b)` where `b` captured `price = 40` | `80` | | `eval("tax = 8", b); eval("price + tax", b)` | `48` | | `eval("tax = 8", b); tax` in compiled code | `NameError` | | `eval("z = 1"); eval("z")` | `NameError` | Assigning to a local that **already exists** in the scope is different: `eval("price = 50", b)` updates the existing variable, and compiled code in that scope sees the new value, because the variable was already known when the scope was parsed. ## File, line and errors The third and fourth arguments set the file name and starting line reported for the evaluated code. When you pass a binding but no file name, the code does not inherit the binding's location; backtraces point at an `(eval at ...)` location naming where `eval` was called. Errors raised inside the string propagate to the caller like any other exception, and a malformed string raises `SyntaxError` at the call. ## Mistakes to avoid - Expecting a local assigned inside `eval` to be usable by the next line of the method. - Expecting two bare `eval` calls to share a local that the first one created. - Thinking a binding only carries local variables; it carries `self` and constant scope too. - Using `eval` where a plain method call, `send` or a hash lookup would do; string evaluation is slower to run, harder to read and dangerous with input. ## When eval with a binding is the right tool It is rare in application code. It appears in template engines that render text against a caller-supplied scope, in debugging consoles that evaluate what you type in a paused frame, and in tests of such tools. Everywhere else, pass values explicitly.