Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42235
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.net designates 213.165.64.20 as permitted sender)
Message-ID: <4943FA42.3000806@gmx.net>
Date: Sat, 13 Dec 2008 19:09:06 +0100
User-Agent: Thunderbird 2.0.0.17 (X11/20080914)
MIME-Version: 1.0
To: Ilia Alshanetsky <ilia@prohost.org>
CC: Scott MacVicar <scott@macvicar.net>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <2D85B33E-889B-4214-9BB8-A12EFFFC641E@macvicar.net> <FB99B6B8-A41C-4076-9CA1-646814E422B9@prohost.org>
In-Reply-To: <FB99B6B8-A41C-4076-9CA1-646814E422B9@prohost.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Removing basic types from our JSON parser
From: chris_se@gmx.net (Christian Seiler)

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