You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This set of changes allows JSON Logic engine to more strictly honor sugaring in most methods.
While the operators I implemented were compatible with the base spec, the interpreter was not implemented to actually sugar / desugar single arguments. In terms of compatibility, this has not created issues for anyone, but it was possible to add new operators that would not receive arrays as arguments.
I considered this to be a good thing / an option to be flexible, but with https://github.com/json-logic, I'd like to try to be more rigid with what I allow.
However, I've compromised by allowing users to add a flag to enable them to say `optimizeUnary` on an operator. This argument is used to signify "Hey, I support arrays, but I also support direct input if you want to invoke me with that". This allows my compiler & optimizer to avoid array destructuring overhead, which can actually have semi-significant impact (it did in the Handlebars JLE Library)
Because this change makes adding operators a bit more rigid, and semi-ensures that args will always be an array, I'm bumping the major version flag once more.
I've also changed the layout for some of my tests. Over time, I'm going to move more JSON files into the `suites` directory.
* @param {{ deterministic?: Boolean, async?: Boolean, sync?: Boolean }} annotations This is used by the compiler to help determine if it can optimize the function being generated.
99
+
* @param {{ deterministic?: Boolean, async?: Boolean, sync?: Boolean, optimizeUnary?: boolean }} annotations This is used by the compiler to help determine if it can optimize the function being generated.
0 commit comments