Feature #8631: Add a new method to ERB to allow assigning the local variables from a hash

• Status: Closed
• Assignee: k0kubun (Takashi Kokubun)
• Target version: 2.5

[rosenfeld (Rodrigo Rosenfeld Rosas)]

It would be interesting if ERB could allow a hash instead of a binding for processing the template.

We wouldn't have to do hacks like:

b = OpenStruct.new(hash).instance_eval{ binding }

[sorah (Sorah Fukumori)]

• Status changed from Open to Assigned
• Assignee set to seki (Masatoshi Seki)

Assigning to erb maintainer;

IMO, I recommend you to show example mock-code that uses your proposal, to show what interface (API) do you want :)

[rosenfeld (Rodrigo Rosenfeld Rosas)]

I didn't propose an API because I don't really care about the API as long as it allows us to provide a hash instead of a binding.

If you want an example API that would satisfy me, I'd be happy if we used the same API (ERB#result). If the argument is a hash, use the keys as the local variables and the values as the variable values.

[rosenfeld (Rodrigo Rosenfeld Rosas)]

You can see here how often people want to use a hash to render an ERB template:

https://github.com/search?q=erb+result+openstruct&type=Code&ref=searchresults

And there's no quick way for performing this common procedure. The quickest one seems to be using OpenStruct for that...

[rosenfeld (Rodrigo Rosenfeld Rosas)]

• File feature-8631.pdf feature-8631.pdf added

Attached slide for proposal

[naruse (Yui NARUSE)]

received, thanks!

[ko1 (Koichi Sasada)]

I think it is easy to implement, but not clear what is "self" on ERB evaluation context.

If you provide binding, self will be binding's self.

[matz (Yukihiro Matsumoto)]

I like the idea, but I have one concern.

The binding also has information about the receiver (which defaults to top-level self).
I am not sure whether it's critical or not.

I hope Seki will address this.

Matz.

[matsuda (Akira Matsuda)]

FYI here's an already existing implementation by Seki-san: https://gist.github.com/seki/6449467
Gemified version is here: https://github.com/takkanm/erb_with_hash

[shyouhei (Shyouhei Urabe)]

• Related to Feature #8643: Add Binding.from_hash added

[nobu (Nobuyoshi Nakada)]

Another implementation:

diff --git a/lib/erb.rb b/lib/erb.rb
index 9483711024..9813b4dc71 100644
--- a/lib/erb.rb
+++ b/lib/erb.rb
@@ -887,6 +887,11 @@
   # code evaluation.
   #
   def result(b=new_toplevel)
+    if b.respond_to?(:each_pair)
+      x = new_toplevel
+      b.each_pair {|k, v| x.local_variable_set(k, v)}
+      b = x
+    end
     if @safe_level
       proc {
         $SAFE = @safe_level

[hsbt (Hiroshi SHIBATA)]

• Assignee changed from seki (Masatoshi Seki) to k0kubun (Takashi Kokubun)
• Target version set to 2.5

[k0kubun (Takashi Kokubun)]

There's a problem that a receiver is unclear and not configurable if argument is only a Hash object. To address the problem, we need to have both anything for a receiver (of course Binding is okay) and a Hash object in arguments.

Even in that case, most users of this feature will want to pass only a Hash object as argument. So we want to pass a Hash object with default option for its receiver, without breaking backward compatibility.

To solve all those problems, I propose to use keyword argument like https://github.com/ruby/ruby/pull/1618.

Following is example use case. I think it's fairly easy to use and understand what it does.

ERB.new('<%= my_local %>').result(locals: { my_local: 'value' })

[k0kubun (Takashi Kokubun)]

I found that my suggestion is a little hard to implement to avoid argument modification. It got a little ugly https://github.com/ruby/ruby/pull/1618/commits/ed1c1e520eec6cb96f1eae88bef2fa4ac54a3e6c.

Anyway, currently we have 3 possible choices.

1. Proposed one (implementation is suggested by nobu): ERB.new(*).result({ foo: bar })
2. Seki-san's patch (erb_with_hash): ERB.new(*).result_with_hash({ foo: bar })
3. My suggestion: ERB.new(*).result(locals: { foo: bar })

From user's point of view, 1 is okay but a little confusing that it can take multiple types in the same argument, 2 is good but a name is long and 3 is the best.
From maintainer's point of view, 1 is okay, 2 is the best and 3 is a little hard.

So all of them have trade-offs. While I feel it's overkill to make it capable of having both Binding and Hash as arguments, I personally want to introduce 3 because it's easy to use and not confusing.

I want your opinions about this.

[k0kubun (Takashi Kokubun)]

Umm, I noticed that actually the length of "ERB.new(*).result(locals: {a: b})" is the same as "ERB.new("aaa").result_with_hash(a: b)". So the long name of 2 seems not a problem compared to 3.

Then, my final personal preference is Seki-san's 2 (erb_with_hash) https://github.com/ruby/ruby/pull/1623. It's already used by some users of erb_with_hash.gem and I think the method is good to have in ERB.

[k0kubun (Takashi Kokubun)]

• Status changed from Assigned to Feedback

[rosenfeld (Rodrigo Rosenfeld Rosas)]

I would already suggest a new name when I read about the problems with overriding the current method, so I would agree that 2 would be a better approach, I'm just not sure which name would be best. I like result_with_hash, but it could be result_from_locals or result_from_hash.

Or maybe ERB.new(str, locals: {a: b}).result?

[k0kubun (Takashi Kokubun)]

Or maybe ERB.new(str, locals: {a: b}).result?

For this case, it would have the same problem as ERB.new(str).result(locals: {a: b}) because it can have both binding and locals. In that case, adding locals to given binding is hard to maintain. Also, if we want to avoid the situation, raising error for that case does not seem a good idea (method should be separated in that case, especially for "3").

I'm just not sure which name would be best. I like result_with_hash, but it could be result_from_locals or result_from_hash.

Then, the remaining problem is only the name of result_with_hash counterpart. Possible choices are:

• result_with_hash
• result_from_locals
• result_from_hash

What this method does is "rendering template with a context that given local variables are set and returning the result". It's not result derived from only local variables. While "locals" is longer than "hash", it describes not type of argument but its actual content.

So I prefer "result_with_locals" ("render_with_locals" may be better but it should be unified with "result"). If you use the method with that name, I'm okay to add that.

[rosenfeld (Rodrigo Rosenfeld Rosas)]

I'm actually fine with whatever name you prefer. result_with_locals and render_with_locals are both fine to me. Thanks a lot!

[k0kubun (Takashi Kokubun)]

I discussed about this with Seki-san.

For name, I rethought that "result_with_locals" sounds to use caller's local variables. Since "result_with_hash" doesn't seem to mean it and is shorter, we agreed "result_with_hash" is the best.

For receiver problem, since TOPLEVEL_BINDING.dup (and its receiver, main) is already used, we agreed it's consistent and safe to use TOPLEVEL_BINDING.dup.

As Seki-san agreed to introduce this in person, I'm going to merge https://github.com/ruby/ruby/pull/1623.

[k0kubun (Takashi Kokubun)]

• Status changed from Feedback to Closed

Applied in changeset trunk|r58891.

---

erb.rb: Add ERB#result_with_hash

[ruby-core:55985] [Feature #8631] [fix GH-1623]

[rosenfeld (Rodrigo Rosenfeld Rosas)]

Awesome, thanks!