Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42287
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error)
Message-ID: <49479DB6.1070602@macvicar.net>
Date: Tue, 16 Dec 2008 12:23:18 +0000
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: troels knak-nielsen <troelskn@gmail.com>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <494698D3.2030801@lerdorf.com>	 <bd9320b30812151009t29bc6283m79f8985022cd7e2b@mail.gmail.com>	 <10845a340812160348k18bffb0et1e75cf345b5e42cc@mail.gmail.com>	 <494797BE.3060505@macvicar.net> <98b8086f0812160420u12a92ac5v2c202ef679b542e0@mail.gmail.com>
In-Reply-To: <98b8086f0812160420u12a92ac5v2c202ef679b542e0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  troels knak-nielsen wrote: > On Tue, Dec 16, 2008 at 12:57
	PM, Scott MacVicar <scott@macvicar.net> wrote: >> For now I'll be leaving
	it as is and adding a JSON_STRICT_ENCODE >> parameter to the options flag.
	So you can use >> >> json_encode($var, JSON_STRICT_ENCODE); >> > > I'm really
	not a fan of named constants to change the semantics of a > function like
	that. Not to mention that it's a pita to type out, so > nobody would bother.
	It also doesn't address the crux of the matter - > That the name json_encode
	is slightly misleading, in that it may or > may not emit json. > > Would
	it be a problem to introduce a second function (js_encode?) > instead? It
	could work as json_encode does today, and json_encode > could then be changed
	to raise a warning on illegal input. I realise > that this means breaking
	existing scripts, but it's a trivial change, > and if it's announced in advance,
	people should have time to make that > sed -r '/json_encode/js_encode/g'
	to their code base. > [...] 
	Content analysis details:   (-4.3 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
	0.1 AWL                    AWL: From: address is in the auto white-list
Subject: Re: [PHP-DEV] json_encode()
From: scott@macvicar.net (Scott MacVicar)

troels knak-nielsen wrote:
> On Tue, Dec 16, 2008 at 12:57 PM, Scott MacVicar <scott@macvicar.net> wrote:
>> For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
>> parameter to the options flag. So you can use
>>
>> json_encode($var, JSON_STRICT_ENCODE);
>>
> 
> I'm really not a fan of named constants to change the semantics of a
> function like that. Not to mention that it's a pita to type out, so
> nobody would bother. It also doesn't address the crux of the matter -
> That the name json_encode is slightly misleading, in that it may or
> may not emit json.
> 
> Would it be a problem to introduce a second function (js_encode?)
> instead? It could work as json_encode does today, and json_encode
> could then be changed to raise a warning on illegal input. I realise
> that this means breaking existing scripts, but it's a trivial change,
> and if it's announced in advance, people should have time to make that
> sed -r '/json_encode/js_encode/g' to their code base.
> 

We already have PHP_JSON_HEX_QUOT, PHP_JSON_HEX_TAG, PHP_JSON_HEX_AMP
and PHP_JSON_HEX_APOS as options for json_encode, this would just be
adding another bitmask.

In the future if need be we can make it the default value so it raises a
warning. I have no interest in doing a js_encode functions as it opens
us up to implementing a lot more functionality.

The appealing this about json is that its a subset of JavaScript.

Scott