Re: RFC json_validate() - status: Under Discussion

User-land implementation of is_valid_json() https://gist.github.com/dmsnell/aa9f0f281eb124a3bdafe84c7475b398 > Just Want to remind that this discussion is not about "a json parser can be written in >PHP or not?".> We Have a JSON parser already in the core, ready to be use for validation. > Does it make sense to have another parser in User land to do validation if We already have one? > Is there a better way to do validation other than json_decode? > Has anyone actually put that claim to the test? [118490] Although I chimed in before [118342] I modified my parser to be [non-trivial] and wanted to share the results. Given the hesitation about introducing this function into the language itself I want to make sure we're comparing facts when discussing user-land implementations vs. a core function. My updated [parser] consumes no more memory than is required on the stack when recursing into arrays and objects (basically no extra memory) and runs around half as fast as json_decode() (only about 50% slower if we skip validating string values). I've run the results through the [JSONTestSuite] to verify behaviors (especially the edge-cases and situations which are implementation-defined) and to ensure that they match the behavior of json_decode(). When asking if we want this in Core or if it's too hard to do reasonably-well in user-land, here is an example where we have working code that fulfills the same need as this RFC. If the handful of motivating cases were updated to use this user-land implementation would we still feel the need to add this to the language? (Noting too that even though it's third-party code, it's a single file that can be copy/pasted without importing any library or needing to fill out the typical request forms for code inclusion). If this does land in Core then can we at least do better on the performance than json_decode()? I believe that the JsonChecker library would perform much better in C than its PHP port (though it fails a few tests and also handles certain implementation-defined inputs differently than json_decode() does). If we're doing sufficiently less in json_validate() than we are in json_decode() I would want that; would want it to be much faster. The strongest argument I can see for adding this to the language is that it would behave exactly as json_decode() does; I feel like the argument that there's strong need for it to be slightly weaker. > What is the reasoning behind the name? I can't find it explained in the RFC. > What about other alternatives like is_json or validate_json?  Discussion about the name is found in the original thread, [118310]. > It's not entirely clear *what* that Magento code is doing, but it's definitely not >just validation: > the output of json_decode is passed to  $this->_jsonEncoder->encode(); if it was just > validating, > it would  return $input, or true. My guess is that like the Symfony example > it is  "pretty-printing" existing JSON strings. [118477] In several of the examples it _is_ just validating the JSON input. We can see several frameworks offering a form of declarative input validation for their endpoint handlers.. You can say "this expects a JSON document" and the framework will fail the request if the input can't be decoded as JSON. We could make the argument that it would be better yet to go ahead and use the parsed JSON and pass it off to the eventual handler code, but I think there could be several layers of indirection and abstraction making that refactor a bit unclear. These cases seem to revolve around the primary question: "I want to know if this input could be parsed as JSON but I know nothing else about what some other code is going to do with it." [118490]: https://news-web.php.net/php.internals/118490 [118342]: https://news-web.php.net/php.internals/118342 [118477]: https://news-web.php.net/php.internals/118477 [118310]: https://news-web.php.net/php.internals/118310 [non-trivial]: https://news-web.php.net/php.internals/118502 [parser]: https://gist.github.com/dmsnell/aa9f0f281eb124a3bdafe84c7475b398 [JSONTestSuite]: https://github.com/nst/JSONTestSuite