rfc:json_validate

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:json_validate [2022/09/19 21:21] juan_moralesrfc:json_validate [2022/10/08 14:51] (current) – Implemented. timwolla
Line 3: Line 3:
   * Date: 2022-08-14   * Date: 2022-08-14
   * Author: Juan Carlos Morales, dev.juan.morales@gmail.com   * Author: Juan Carlos Morales, dev.juan.morales@gmail.com
-  * Status: Under Discussion+  * Status: Implemented 
 +  * Target Version: PHP 8.3
   * First Published at: http://wiki.php.net/rfc/json_validate   * First Published at: http://wiki.php.net/rfc/json_validate
   * Implementation: https://github.com/php/php-src/pull/9399   * Implementation: https://github.com/php/php-src/pull/9399
Line 11: Line 12:
  
 Most userland implementations use json_decode() which by design generates a ZVAL(object/array/etc.) while parsing the string, ergo using memory and processing that could be save. Most userland implementations use json_decode() which by design generates a ZVAL(object/array/etc.) while parsing the string, ergo using memory and processing that could be save.
 +
 +The proposed function will use the exact same JSON parser that already exists in the PHP core, which is also use by json_decode(), this garantees that what is valid in //json_validate()// is also valid in //json_decode()//.
  
 ===== Proposal ===== ===== Proposal =====
Line 119: Line 122:
 ==== Complexity added in the core ==== ==== Complexity added in the core ====
  
-At the moment, there is a JSON parser in the core, used by json_decode to do its job, so there is no need to write a new JSON parser for this RFC; the proposed function will use the existing JSON parser exclusively to parse an string without generating any object/array/etc. in memory for it.+At the moment, there is a JSON parser in the core, used by //json_decode()// to do its job, so there is no need to write a new JSON parser for this RFC; the proposed function will use the existing JSON parser exclusively to parse an string without generating any object/array/etc. in memory for it.
  
 ===== Reasons NOT to have json_validate() function in the core ===== ===== Reasons NOT to have json_validate() function in the core =====
Line 152: Line 155:
 The ability to throw an exception on error was removed from the implementation, as this was pointed not only by most of user in the mailing list (with good reasons), but also during code review; as it does not make sense to have such a behavior. The ability to throw an exception on error was removed from the implementation, as this was pointed not only by most of user in the mailing list (with good reasons), but also during code review; as it does not make sense to have such a behavior.
  
-I also hae to admit that after they showed their arguments, I changed my mind, and now I also think it makes sense to have such a behavior in the function.+I also have to admit that after they showed their arguments, I changed my mind, and now I also think it makes sense to have such a behavior in the function.
  
 So removing the ability to throw exception on error was removed from implementation. So removing the ability to throw exception on error was removed from implementation.
  
 ==== Others ==== ==== Others ====
-  * I removed 3 of the provided examples because did not adjust to the RFC purpose or were not clear. +  * I removed 3 of the originally provided examples in the RFC because did not adjust to the RFC purpose or were not clear. 
-  * Had to adjust the wording regarding disadvantage of using json_decode() as pointed here:+  * I had to adjust the wording in this RFC document regarding disadvantage of using json_decode() as pointed here:
     * [[https://github.com/php/php-src/pull/9399#discussion_r955626844|PR comment from user drealecs]]     * [[https://github.com/php/php-src/pull/9399#discussion_r955626844|PR comment from user drealecs]]
  
Line 171: Line 174:
 ===== RFC Impact ===== ===== RFC Impact =====
 This RFC has no impact on SAPIs, existing extensions, Opcache, etc. This RFC has no impact on SAPIs, existing extensions, Opcache, etc.
- 
-===== Open Issues/Questions ===== 
- 
-==== Returning BOOLEAN or INT ==== 
- 
-**Option 1)** Return boolean, TRUE for valid string or FALSE for invalid. In case of error, use the functions json_last_error() and json_last_error_msg() to get the proper error. This is how is implemented at the moment. 
- 
-**Option 2)** Return integer number, following the already existing constants for json errors, being the return values as: 
- 
-JSON_ERROR_NONE 
-  No error has occurred 
- 
-JSON_ERROR_DEPTH 
-  The maximum stack depth has been exceeded 
- 
-JSON_ERROR_STATE_MISMATCH 
-  Invalid or malformed JSON 
- 
-JSON_ERROR_CTRL_CHAR 
-  Control character error, possibly incorrectly encoded 
- 
-JSON_ERROR_SYNTAX 
-  Syntax error 
- 
-JSON_ERROR_UTF8 
-  Malformed UTF-8 characters, possibly incorrectly encoded 
- 
-JSON_ERROR_RECURSION 
-  One or more recursive references in the value to be encoded 
- 
-JSON_ERROR_INF_OR_NAN 
-  One or more NAN or INF values in the value to be encoded 
- 
-JSON_ERROR_UNSUPPORTED_TYPE 
-  A value of a type that cannot be encoded was given 
- 
-JSON_ERROR_INVALID_PROPERTY_NAME 
-  A property name that cannot be encoded was given 
- 
-JSON_ERROR_UTF16 
-  Malformed UTF-16 characters, possibly incorrectly encoded 
- 
- 
-From implementation point of view, is very easy to achieve both options. 
- 
-Personally I prefer Option 1, the BOOLEAN return value, because TRUE is more appeal to the understanding that the json-string is valid ... than returning zero or JSON_ERROR_NONE, which in PHP is a falsy value by design. For me BOOLEAN will avoid confusions in the usage of the function. 
- 
-Option 2 would force the developers to write code like: 
-<code php> 
-if (!json_validate($input)) { 
-    ...code for valid json here ... 
-} 
-</code> 
- 
-<code php> 
-if (json_validate($input) === JSON_ERROR_NONE) { 
-        ...code for valid json here ... 
-} 
-</code> 
- 
-<code php> 
-if (json_validate($input) === 0) { 
-        ...code for valid json here ... 
-} 
-</code> 
- 
-... etc. 
- 
-I also have the feeling that with "Option 2" developers will end up writing a wrapper around json_validate() to use it straight forward in their code. 
- 
-**I prefer Option 1.** , and the implementation is done like that. 
  
 ===== Future Scope ===== ===== Future Scope =====
Line 435: Line 367:
 Someone has also doing exactly this , in JAVA. [[https://stackoverflow.com/questions/3679479/check-if-file-is-json-java|In Java]] Someone has also doing exactly this , in JAVA. [[https://stackoverflow.com/questions/3679479/check-if-file-is-json-java|In Java]]
  
 +===== Vote =====
 +
 +Voting started 2022-09-22 and will end on 2022-10-07 at 00:00:00 UTC time zone.
 +
 +<doodle title="json_validate" auth="juan_morales" voteType="single" closed="true" closeon="2022-10-07T00:00:00Z">
 +   * Yes
 +   * No
 +</doodle>
rfc/json_validate.1663622500.txt.gz · Last modified: 2022/09/19 21:21 by juan_morales