rfc:json_validate
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:json_validate [2022/08/27 15:32] – juan_morales | rfc:json_validate [2022/09/22 04:26] – juan_morales | ||
---|---|---|---|
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: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
* Implementation: | * Implementation: | ||
Line 11: | Line 11: | ||
Most userland implementations use json_decode() which by design generates a ZVAL(object/ | Most userland implementations use json_decode() which by design generates a ZVAL(object/ | ||
+ | |||
+ | The proposed function will use the exact same JSON parser that already exists in the PHP core, which is also use by json_decode(), | ||
===== Proposal ===== | ===== Proposal ===== | ||
Line 119: | Line 121: | ||
==== 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/ | + | 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/ |
===== Reasons NOT to have json_validate() function in the core ===== | ===== Reasons NOT to have json_validate() function in the core ===== | ||
Line 144: | Line 146: | ||
* The user also provided an implementation of a JSON parser written in pure PHP. https:// | * The user also provided an implementation of a JSON parser written in pure PHP. https:// | ||
- | ===== Changes in the RFC hat happened during discussion ===== | + | ===== Changes in the RFC that happened during discussion ===== |
- | ====== Throw Exception on error ====== | + | ==== Throw Exception on error ==== |
- | In my initial implementation, | + | In my initial implementation, |
- | The ability to throw an exception on error was remove | + | The ability to throw an exception on error was removed |
- | 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. |
- | ====== Others | + | So removing the ability to throw exception on error was removed from implementation. |
- | * I removed 3 of the provided examples 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: | + | ==== Others ==== |
+ | * I removed 3 of the originally | ||
+ | * I had to adjust the wording | ||
* [[https:// | * [[https:// | ||
Line 169: | Line 173: | ||
===== 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/ | ||
- | |||
- | ====== Returning BOOLEAN or INT ====== | ||
- | |||
- | Option 1) Return boolean, TRUe for valid string or FALSE for invalid. In case of error, rely on 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, we just have to come to an agreement. | ||
- | |||
- | 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, | ||
- | |||
- | Option 2 would force the developers to write code like: | ||
- | <code php> | ||
- | if (!json_validate($input)) { | ||
- | ... | ||
- | } | ||
- | </ | ||
- | |||
- | <code php> | ||
- | if (json_validate($input) === JSON_ERROR_NONE) { | ||
- | ... | ||
- | } | ||
- | </ | ||
- | |||
- | <code php> | ||
- | if (json_validate($input) === 0) { | ||
- | ... | ||
- | } | ||
- | </ | ||
- | |||
- | ... etc. | ||
- | |||
- | I also have the feeling that with " | ||
- | |||
- | **I prefer Option 1.** , but this is still open. | ||
===== Future Scope ===== | ===== Future Scope ===== | ||
Line 433: | Line 366: | ||
Someone has also doing exactly this , in JAVA. [[https:// | Someone has also doing exactly this , in JAVA. [[https:// | ||
- | ===== Open questions | + | ===== Vote ===== |
- | **Should we remove the capability of json_validate() to use the flag JSON_THROW_ON_ERROR? | + | |
- | During the discussion in the inernals mailing list the user Rowan Tommins | + | Voting started 2022-09-22 and will end on 2022-10-07 at 00:00:00 UTC time zone. |
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </doodle> |
rfc/json_validate.txt · Last modified: 2022/10/08 14:51 by timwolla