Critical impossibility for truthiness validation in PHP

[luismoyano]

Hello JSON Logic! Recently I found myself with a small detail while working on a PHP port of shiny_json_logic_ruby:

It was accepted that we would work with or without syntactic sugaring so both of these would work:

{ "+": 1 } => 1
{ "+": [1] } => 1

and it was also accepted that arithmetic operations with types different than numbers would throw a NaN

{ "+": {} } => NaN

Unless we do Arrays where we understand absense of numbers:

{ "+": [] } => 0

But PHP parses json with json_decode and he associative flag (set to false as a default) but when set to true it renders hashes as the native php associative arrays, thus this happens:

json_decode('{"+" : {}}', true) // => ["+" => []]

Aaaaaand because of this

ShinyJsonLogic::apply(json_decode('{"+" : {}}', true)); // => 0 It should be NaN!!!!

Having agreements in place already I don't think there's too much we can do about it, but I want to report it because I think we didn't thought about the possibilities in all languages when accepting/rejecting proposals and this research should probably be part of the pipeline process.

I'd love to hear your opinions, thanks!!

[TotalTechGeek]

Full agreement this kind of thing should be brought up in our discussions; and why we need representation from the broader ecosystem!

I was unaware of this quirk in PHP... that {} would be converted to an array with json_decode.

Is this... typical? Why does it do this? I'm sure there's a reason -- it's just surprising to me.

If it would smooth things out, I could be open to potentially specifying that {} would follow the numeric conversion chain of {} is falsy and thus cast to zero. It's not my preference, but it's also not something I'm totally resistant to.

But I'm unsure if that fully resolves issues, what happens if you use , true and it uses a non-empty object?

[TotalTechGeek]

Also, one thing I'd like to clarify, this is why we have the phase system :)

The arithmetic operator proposal is still in Phase 1, which tries to validate the proposal against multiple implementations.

In Phase 1 / 2:

- During these phases, proposals will be implemented in a few JSON Logic runtimes, if relevant.
- If significant friction is encountered or reasonable community concerns are raised, the proposal may be pulled back to Phase 0.

This could be considered friction / a reasonable community concern, warranting an amendment to the proposal, or at a minimum, discussion around it.

[luismoyano]

@TotalTechGeek I guess I didn't fully understand the phases, thanks for pointing it out!

Regarding php stuff; Same as you I've been trying to contact Jeremy with little success to ask for help on some stuff and also to collaborate in the php library but it has not been possible so ported my Ruby one.

In PHP there's this thing about Arrays and objects being the same in its core, thus you can define [1,2,3] and ['a' => 1, 'b' => 2, 'c' => 3] and both of them are Array. This is how most php devs work making impossible to distinguish between let's call it hash-array and array-array when empty. Both are the same!

This is a blocker for the invalid operation proposal in PHP since there's no way to fulfill it... Nonetheless, there's one important thing to keep in mind: Php also implements stdClass which is equivalent to a JS object or a Ruby's OpenStruct and when parsing json from files unless you specifically request not to use it with the flag, it'll use these objects instead of Arrays. This is good news for us because the spec would work by default in this cases, but it'll likely fail if the user passes a JSON built within the php runtime as most devs just work with arrays, using stdClass manually feels weird and uncomfortable in this language.

I don't know what to do here... I'd also prefer to throw an error but it just won't rub correctly with php.

[rmannibucau]

You can provide an Array wrapper to ensable it, not as native but works and compensate langagues lcks

[luismoyano]

@rmannibucau Can you elaborate? The issue comes from outside of the engine;

If a user writes ["+": [1]] or ["+": ["x" => 1]] we can know what they meant by the contents of the array but what if they pass ["+": []] Is this an object or an array? PHP does not make distinctions... How could wrapping help? Should we request devs to use a wrapper provided by the library before executing their rules? Not sure if I understand correctly 😓

[rmannibucau]

@luismoyano point is to use ["+": new Array([])] - which also means ["+": new Array([1])] since value is likely in a dynamic part, but the point is that it is common to compensate what the language doesnt offer by wrappers or metadata - see how js is typed with comments for ex. Using a typed API in PHP is not crazy IMHO. The alternative is to provide hints in the JSON-Logic impl: ["+": [1], "$hint":{"type":"array"}] or alike. Overall point is there is no real blocker IMHO and solutions are there since years for this kind of limitations.

[luismoyano]

From those two solutions I like the wrapper better because the second one also breaks a standard convention for JSONLogic being operations are hashes of only one key. Including a hint would break unaware implementations overnight and would force major changes along the whole standard.

On the other hand, the thing I dislike about the wrapper is that it does not fully solve the common case of rules coming from json files where you'd just parse it and pass it to the engine, it only makes sense in a context where you as a developer are shaping the json object by hand... Not sure how many use cases like that exists around...