Issue #12931 has been updated by Samuel Williams.


Nobuyoshi Nakada wrote:
> Since local variables and constants depend on the context, it won't be able to be "cached," as a `Proc` compiled other place.
> So I think it isn't worth.

That makes sense.

So, to clarify, you are saying that there is no way to reuse the compiled proc? It would need to be recompiled?

From my POV, I guess the benefit of this is duck typing.

If performance was the same of eval, it would be acceptable, but if there is some way it could be better, that would be awesome.

----------------------------------------
Feature #12931: Add support for Binding#instance_eval
https://bugs.ruby-lang.org/issues/12931#change-61506

* Author: Samuel Williams
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Many people would probably like to use `binding.instance_eval` when executing templates. The reason for this is because `binding.eval` is slow.

The use case is template rendering, e.g. systems like ERB.

In my template renderer, I did have

```ruby
			if Binding === scope
				# Slow code path, evaluate the code string in the given binding (scope).
				scope.eval(code, @buffer.path)
			else
				# Faster code path, use instance_eval on a compiled Proc.
				scope.instance_eval(&to_proc)
			end
```

The binding path is several orders of magnitude slower because the code is a string and must be parsed, compiled, etc. But, `to_proc` path can be cached.

In terms of duck typing, it would be nice if binding implemented `#instance_eval` and would allow passing a block.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>