-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Strict mode" the same behavior as in ruby's #269
Conversation
…se of new Filters class(immutable)
…e in it, counter should be moved in context (probably as registry)
* </code> | ||
*/ | ||
public enum ErrorMode { | ||
strict, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since they're enum constants, they should be all-uppercase (STRICT, WARN, LAX)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I simply wanted to follow ruby, so I treat ruby literal as a lower-case enum. Still, changing this probably makes more sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I'm hoping we can add some automated checks with PMD, Checkstyle, Spotbugs, etc. They're really helpful. That would come with either adhering more to the standard Java conventions or adding a bunch of exceptions. I'd lean on the former, with very few exceptions only.
@Deprecated | ||
public TemplateContext(TemplateContext parent, Map<String, Object> variables) { | ||
this(variables, parent); | ||
public LiquidSupport evaluate(final Object variable) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is so much cleaner 👍
This looks good overall. Even if not all to-dos are met, tests pass. The earlier we get this in the better :) 👍 Please see my additional commit below for a regression I just found after clearing up all the other warnings. |
antlr rightfully complains: "rule output contains an optional block with at least one alternative that can match an empty string" (which hints at a potential performance problem). This is due to "not_out_end" matching with "*" (which can yield an empty string), even though we already specify "?" at "unparsed=not_out_end?". Fix the parser grammar, and adjust two test cases where we actually tested for that undesired behavior. Also see https://stackoverflow.com/questions/26041293/antlr-4-warning-rule-contains-an-optional-block-with-at-least-one-alternative for an explanation. Regression introduced in bkiers#269
As a result of detected problems in #267
todos:
assign
Shopify/liquid#1102 according to existing logic (lax vs strict)Filters
class(immutable)