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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
