json-logic-kmp
json-logic-kmp copied to clipboard
Checking on Maintenance / Would you be interested in contributing to a spec?
Hey there! 👋🏻
And just a heads up, pieces of this message have been copy-pasted, but I've taken a look through the source code of this project; I noticed your issue here: https://github.com/jwadhams/json-logic/issues/39
I maintain a JSON Logic implementation in JavaScript called json-logic-engine.
I wanted to reach out and inquire:
- Is this project still something you're interested in maintaining? (I ask this of every project, but I see this one has significantly more support than most of the other ones)
- Would you be interested in working with a community of other JSON Logic maintainers to help develop a more rigorous specification, so we can resolve compatibility issues between implementations?
To be clear... this would be a community effort -- I've been trying to get a hold of Jeremy for a few years now, but I haven't had much success chasing him down 😅 . If he takes notice, I'd love to have him involved.
My goal though is to get a dialog going between different maintainers and build a spec + compat table so JSON Logic can be more beneficial to folks.
There are some quirks with different implementations, some ambiguities in the "spec" we have now, and some impossible behaviors that I think would be helpful for the community to address.
Examples of issues I think need discussed & spec'd:
- Data: How do you access
{ '': 1 }? - Data: How do you access
{ 'hello.world': 1 } - Truthiness: straightforward, but a compat table might be helpful
- How do you handle
{ "!": [0] }vs{ "!": 0 }-- this one is more straightforward; but a common compat issue. - How do you handle
{ "!": { "var": "data" } }where data resolves to[0], is it treated like[[0]]or[0]? - How do you access context in iterators?
{filter: [{var: 'arr'}, {'===': [{var: 'item'}, {var: '../../choice'}]}]}; explanation: In most implementations, you're unable to access above context in your iterator, so you can't use data to add numbers together, or filter things out. .length, shouldvarin JSON Logic have a dedicated handle to allow a user to fetch.lengthif the property does not exist on the object naturally? Most implementations do not handle this. This makes logic incompatible in between interpreters; so should.lengthbe treated as a special path, or be given a reserved operator 😉
My hope is to get folks discussing backwards compatible approaches, and help provide resources to projects to help iron out implementation differences.
So:
- Would you be interested in participating?
- If not interested in the spec, would you be interested in receiving PRs based on community input?
Project specific acknowledgements (other than what I decorated some of the text above with)
- Awesome work on this! It's pretty cool that you're supporting several platforms
addStandardOperationvsaddFunctionalOperation-- this is one of the few engines to support user-land control structures; which is really nice!- Really dumb question, but do you have a recommended way to parse & pass JSON into the evaluator, without going through the builders?