Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42286
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.221.20 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=BciCzalwF/O9HLU5RrkMY+SLGtjvbzzMGHFuCo42oKCjuIfIfmd8GMoRKqpWYRG6xs
         y7lrRwDUeZHCmw0EaQG1YR09X75SDayM2a4I7rSjy9KM0m9nEYkRLOKVvMCDwkCbXCsB
         AWl6Pol1GzChBbHLSj0snhimtK+5CLfad1XJA=
Message-ID: <98b8086f0812160420u12a92ac5v2c202ef679b542e0@mail.gmail.com>
Date: Tue, 16 Dec 2008 13:20:57 +0100
To: "Scott MacVicar" <scott@macvicar.net>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>
In-Reply-To: <494797BE.3060505@macvicar.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <494698D3.2030801@lerdorf.com>
	 <bd9320b30812151009t29bc6283m79f8985022cd7e2b@mail.gmail.com>
	 <10845a340812160348k18bffb0et1e75cf345b5e42cc@mail.gmail.com>
	 <494797BE.3060505@macvicar.net>
Subject: Re: [PHP-DEV] json_encode()
From: troelskn@gmail.com ("troels knak-nielsen")

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.

--
troels