liquid: Can’t use symbols as hash keys for local variables in Liquid::Template#render

Here’s a minimal test case:

Liquid::Template.parse('Hi, {{name}}!').render(:name => 'Cody')  #=> 'Hi, !'
Liquid::Template.parse('Hi, {{name}}!').render('name' => 'Cody') #=> 'Hi, Cody!'

This is especially annoying because as a result you can’t use Ruby 1.9’s new hash syntax:

Liquid::Template.parse('Hi, {{name}}!').render(name: 'Cody')  #=> 'Hi, !'

This problem occurs for me using both 2.3.0 and 2.2.2.

About this issue

Original URL
State: closed
Created 13 years ago
Comments: 21 (9 by maintainers)

Most upvoted comments

Liquid has traditionally used strings for variables names because they could be user defined and before Ruby 2.2 symbols weren’t garbage collected. So in the past we would have had at best a memory leak and at worst a DoS attack vector from using symbols internally to represent variable names.

If liquid uses strings internally but accepted symbols from the application code, then this library would need to convert the symbols to strings using Symbol#to_s. In other words, we wouldn’t be benefiting from using symbols as Hash keys and would be allocating new string objects for every call to Symbol#to_s.

Ruby 2.1 isn’t maintained upstream anymore, so we should consider dropping support for it and switching to using symbols internally in liquid to represent variables. For backwards compatibility, we could convert String variables names passed in from the application code, but String#to_sym doesn’t have the performance concerns that Symbol#to_s has.

So not only can we make this library more pleasant to use by supporting the Ruby 1.9 hash syntax, but we should also be able to improve performance by using Symbol hash keys.

dylanahsmith on Jun 6, 2018

Maybe it’s time to reconsider this decision? We use liquid in our app and these hash.stringify_keys and key.to_s don’t look good in code. And yes - they hit the performance anyways 😃

arg on Nov 6, 2013