The meaning I gave is to start at the lower bound and step by one. This has the
advantage of having (n..m) and ((n.to_f)..(m.to_f)) behave the same. Another
thing we could do that have this same property is to cast bounds to integer.
This would do the right thing if there is a floating point rounding error, but I
feel it is more surprising for cases such as (1.5..8).
Note that it is not possible to create ranges with floating point boundaries
directly in Liquid at the moment. However, since there is no distinction between
Ruby and Liquid ranges, a drop can introduce such a value by returning it.
It should now be harder to read the docs and miss the extra letter required for reversed compared to reverse, which causes a fairly generic syntax warning when trying to reverse sort a collection in a for loop.
This could be used to preserve the old default of rendering
non-Liquid::Error messages or for providing default behaviour like error
reporting which could be missed if the exception renderer needed to be
specified on each render.
These errors may contain sensitive information, so is safer to
render a more vague message by default.
This is done by replacing non-Liquid::Error exceptions with a
Liquid::InternalError exception with the non-Liquid::Error accessible on
through the cause method. This also allows the template name and line
number to be attached to the template errors.
The exception_handler render option has been changed to exception_renderer
since now it should raise an exception to re-raise on a liquid rendering
error or return a string to be rendered where the error occurred.
The argument `truncate_string` is now coerced into a string to avoid
`NoMethodError`s. This is mostly for added resiliency. It is doubtful
that someone would actually intent to use a number as truncate string,
but accidentally supplying one is entirely possible.
When including a template which is not defined, the exception raised is
*undefined method `split` for nil:NilClass*
This occurs for a scenario like the following:
`{% include nil %}`
or
`{% include undefined-var %}`
Making the code raise an argument error to allow better understanding of
the include error
Currently, `truncatewords` raises a TypeError when the argument
`truncate_string` is an interger. This PR forces string coercion for any
value provided for this argument. Thus,
```ruby
assert_equal 'one two1', @filters.truncatewords("one two three", 2, 1)
```
holds true. Another option would be to raise a `Liquid::ArgumentError`.
What is preferred?
Performance is increased by doing this:
require 'benchmark'
require 'tempfile'
n = 50000
test = File.expand_path(Tempfile.new('foo'))
Benchmark.bm(20) do |x|
x.report("Regex:") do
n.times { test =~ /\A#{test}/ }
end
x.report("String#start_with?:") do
n.times { test =~ test.start_with?(test) }
end
end
Benchmark result:
user system total real
Regex: 0.440000 0.010000 0.450000 ( 0.447357)
String#start_with?: 0.000000 0.000000 0.000000 ( 0.006313)
