RuleCondition provides limited opportunities to optimize rule matching for the developers. Its meaning is to be a predicate, but its components are joined via logical AND operator and don't allow to provide alternatives within the same rule. It'd cause exponential growth of number of rules if it is needed to match requests with values from certain sets.
The proposal is to replace
CompiledRuleCondition object and predicate arrow functions taking as arguments the relevant queries objects. The only allowed AST nodes within these functions are
- returns of boolean values
- boolean operations on boolean values
== is considered the same as
Map.prototype.has calls with string and integer arguments, also checking presence of strings as keys of objects that are not special
- accesses of properties of request objects
- calls of other arrow functions matching the criteria with arguments matching the criteria.
Loops and recursion are disallowed.
All string properties of the request object returning values from a certain set become integer enums.
CompiledRuleCondition ctor is called:
- all the objects used within the matcher arrow functions are copied (not necessarily really copied, but the meaning is that their values used for compilation cannot be mutated)
- the matcher arrow function AST is verified taking into account types of each variable and property
- the matcher arrow function is compiled into native code
RuleCondition becomes syntax sugar for initializing
CompiledRuleCondition with an arrow function doing the job and some accessor properties for compatibility.
CompiledRuleCondition second optional argument is
debug, allowing to get a trace of the control flow graph path within the matcher function.