Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96380
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.154 cause and error)
To: Andrea Faulds <ajf@ajf.me>, PHP internals <internals@lists.php.net>
References: <CAGa2bXYGUhihdbMMBQB7FQ6CnmYqrB_x2YVjdZTvT8gDs59oOQ@mail.gmail.com>
 <F0.67.45301.59BBDC75@pb1.pair.com> <1E.58.41968.0CD00085@pb1.pair.com>
Message-ID: <5ccf316a-dac1-2821-b183-a0415fdd7af5@telia.com>
Date: Sat, 15 Oct 2016 14:31:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <1E.58.41968.0CD00085@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Moving utf8_encode() and utf8_decode() to ext/standard
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2016-10-14 kl. 00:42, skrev Andrea Faulds:
> Hi,
>
> This is a follow-up to what I wrote in the utf8_encode()/utf8_decode() 
> discussion earlier:
>
> Andrea Faulds wrote:
>> I would propose something else: remove them from the XML extension, and
>> move them somewhere more fitting, like ext/intl, ext/mbstring or maybe
>> ext/standard. These are generic functions which work on any text, not
>> just XML, and their inclusion is mutually superfluous with respect to
>> XML: if you're decoding XML, you don't necessarily need to convert text
>> to/from UTF-8, and if you're converting text to/from UTF-8, you don't
>> necessarily need to deal with XML. Plus, given the names alone, you'd
>> have no idea they're part of the XML extension.
>
> Since these functions are generic string functions that have no 
> dependency on libxml, I've written a patch to move them to 
> ext/standard, and simplified their code a little bit.
>
> Pull request here: https://github.com/php/php-src/pull/2160
>
> This doesn't currently do any function renaming or aliasing, but I 
> should probably do that next. Plus, the manual still needs updating.
>
> Are there any objections to this move? There'd be no 
> backwards-compatibility break.
>
> Thanks!
>
I think this is a very good way forward. At the moment we are
planning a migration project going from PHP 5.x to 7.x where
the content is mostly coded in ISO-8859-1 and in some places
UTF8.

We use these functions to convert when needed, so removing
them is in my eyes a bad idea since it would hamper our effort
to migrate towards PHP 7. And we want to focus on one thing
at the time. Meaning, not mixing PHP 7 & UTF8 migration. We
can also not justify the cost for moving content to UTF8 since
there is no added value for our end-users in it.

So please keep these functions and don't remove them!

Regards //Björn Larsson