3 ms·
Expressions that will be evaluated at runtime are just strings, no? {"rules": [ "x > 1", "x % 2 = 1" ]} So you will have an "expression parser" to
by linkdd 4y ago
Expressions that will be evaluated at runtime are just strings, no?
{"rules": [
"x > 1",
"x % 2 = 1"
]}
So you will have an "expression parser" to parser your rules, validate them, and execute them. But at least you do not have the edge cases of everything else.
- kevin_thibedeau 4y agoThis sort of hack with control logic was done in XML with Ant. It was a bad idea then and it still is.
- _gabe_ 4y agoAt this point you're already writing your own parser to parse the expressions from the strings. Why not cut out the json completely and make it way more readable? rules = [ x + 1, x % 2 == 1 ]
- giaour 4y agoThose are simple expressions (no multiline blocks, no named symbols, no expressions that call other expressions), and you're still forced to treat them as opaque strings when you use a serialization language for configuration. That may be the best approach for a given project! But if you're using configuration to define an API contract, cloud infrastructure, or a query, you might be better off using a purpose-built DSL like protocol buffers, HCL, or SQL, respectively. That approach can let you define a greater level of expressivity than is allowed in a serialization language like JSON or XML without letting config authors write scripts of arbitrary computational complexity (like they would be able to with config in a scripting language).