Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68708
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain seld.be designates 74.125.83.46 as permitted sender)
Message-ID: <52205E39.5020202@seld.be>
Date: Fri, 30 Aug 2013 10:56:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: internals@lists.php.net
References: <521EE223.9060702@fedoraproject.org> <a8cd026552d20c87664bed10a321612f@mail.gmail.com>
In-Reply-To: <a8cd026552d20c87664bed10a321612f@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]
From: j.boggiano@seld.be (Jordi Boggiano)

On 29.08.2013 09:52, Zeev Suraski wrote:
> I have to say that I'm not wildly enthusiastic about making this change over
> what appears to be a fairly minor comment in the license, and without even
> going into the discussion as to why we want to promote Evil :)
> 
> The main concerns I have are:
> * Downwards compatibility.  We've found one potential issue, how can we
> guarantee that there aren't others when we deal with a completely different
> implementation?  I think that users that bump into apps suddenly breaking in
> obscure edge cases will not be very understanding when we explain to them
> that we did that over a licensing quirk - that I'm willing to bet they'll
> say isn't applicable to them...
> * Performance.  Again, for the same reasons, I think it'll be difficult for
> us to defend this decision in this context as well.  We switched to a 2x
> slower implementation over this?  Really?
> 
> I think that a better alternative would be enabling ext/jsonc to take over
> the ext/json symbol space so that people who care about the license issue,
> and/or are interested in the extra features - will be able to take advantage
> of it as a drop-in replacement.  Debian can come with this switch turned on.

I think it'd be best to resolve this in PHP because otherwise it means
Debian (& Fedora?) users will have the bad surprise of a quirky
implementation when deploying to prod, and I can imagine the
impossible-to-reproduce issues that will follow.

That said, your last proposal of at least having a switch in php like
--enable-evil-json sounds better than the current state. If we do have
an equivalent implementation though we might as well throw away the
existing one instead of keeping two IMO, but that's a detail.

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi