Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69979 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15041 invoked from network); 31 Oct 2013 08:31:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Oct 2013 08:31:05 -0000 X-Host-Fingerprint: 80.4.21.210 cpc22-asfd3-2-0-cust209.1-2.cable.virginm.net Received: from [80.4.21.210] ([80.4.21.210:19836] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A7/50-13434-84512725 for ; Thu, 31 Oct 2013 03:31:05 -0500 To: internals@lists.php.net,Martin Keckeis Message-ID: <52721544.10106@php.net> Date: Thu, 31 Oct 2013 08:31:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 References: <526F98C1.4040607@php.net> <527212E9.7040201@php.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 80.4.21.210 Subject: Re: [PHP-DEV] Re: [RFC] Use default_charset As Default Character Encoding From: krakjoe@php.net (Joe Watkins) On 10/31/2013 08:28 AM, Martin Keckeis wrote: >> I don't see that it is possible to merge the settings from different >> libraries, what if an application is relying on mbstring and iconv having >> different settings ?? >> >> > I think this use case is descibed in the RFC. The default_charset can be > overwritten: > default_charset < php.* < mbstring.*/iconv.* < encoding specified by > functions > > >> It's possible that applications are relying on the separation of their >> settings in order to function properly, is what I am trying to say. >> > > The same like above. > > >> >> The only way you could possibly merge those configuration settings is by >> also merging the functionality, there's no backward compatible way to do >> that, but I can imagine at some time in the future those libraries being >> used to support all of the required input/output/script encoding features >> at the level of Zend. >> >> I don't see how this can move forward and not break stuff ... >> >> > I think it's the same like above...You can override the default setting, so > everything should be fine. > > I'm +1 for this, as there are really to much unnecessary settings around! > How could you override them ?? If they are removed then they cannot be referenced. If they are not being removed then nothing is being simplified ... Cheers Joe