Re: Re: Removing basic types from our JSON parser
| From: | Christian Seiler | Date: | Sat, 13 Dec 2008 18:09:06 +0000 |
| Subject: | Re: Re: Removing basic types from our JSON parser | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-42235@lists.php.net to get a copy of this message | ||
Hi,
>> Basic types were added to our JSON decoder to PHP 5.2.1, this allows
>> one to use json_encode / json_decode on any of our scalar types. Omar
>> correctly identified #38680 as not a bug but it appears that Ilia
>> added support for this anyway violating the RFC [1]. Maybe there was a
>> reason for this but I'm not sure why?
>
> PHP is typeless language, IMO its conductive to this design to allow
> encoding of basic types via json_encode, it reduces the code when
> communicating to/form JavaScript to avoid type detection. While it does
> violate the RFC IMO the convenience of the feature is definitely worth it.
I agree that it's convenient for exporting variables to Javascript. On
the other hand, one should always be lenient when accepting input but
strict when generating output. Having json_encode encode non-arrays and
non-objects by default will probably allow some people to shoot
themselves in the foot when interfacing with other JSON applications.
Thus I'd propose the following:
json_encode already posesses an $options parameter that allows one to
specify certain options for encoding as a bitmask. My proposal would be
to add another option PHP_JSON_ENCODE_BASIC to allow the encoding basic
types.
When set, json_encode("hi") and json_encode(42) will work without any
problem.
When not set, I propose the following behaviour when passing a string or
integer etc.:
* PHP 5.3: An E_DEPRECATED-Warning which mentions the new option but
still return the result.
* PHP 6: Return false or whatever it currently returns when encoding
wasn't possible and throw an E_WARNING.
Regards,
Christian