Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95239
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
To: Yasuo Ohgaki <yohgaki@php.net>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXYGUhihdbMMBQB7FQ6CnmYqrB_x2YVjdZTvT8gDs59oOQ@mail.gmail.com>
 <CAGa2bXbko7a8QQbBXFCU6bdJex-ncxGYNYKMcF+7aeFTqW6L5g@mail.gmail.com>
Message-ID: <15538953-0065-ad02-cfed-26f9c04fea18@gmx.de>
Date: Tue, 16 Aug 2016 19:15:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbko7a8QQbBXFCU6bdJex-ncxGYNYKMcF+7aeFTqW6L5g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 16.08.2016 at 00:00, Yasuo Ohgaki wrote:

> On Mon, Aug 15, 2016 at 12:17 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>> utf8_decode() and utf8_encode() are not needed and causing problems
>> than solving.
>>
>> https://wiki.php.net/rfc/remove_utf_8_decode_encode
>>
>> Proposal
>>   - Document deprecation them now
>>   - Remove them from 7.2
>>
>> I think only few users are using and they shouldn't have problem using
>> mbstring/iconv/intl functions.
>>
>> Any comments?
> 
> Many people concern about BC. It's reasonable.
> How about document deprecation of them now? And not mention when they
> will be removed. It may exist for long, but users are better to use generic
> encoding conversion functions.
> 
> The additional note for them might be
> 
> utf8_encode/decode() is deprecated in favor of other encoding
> conversion features. e.g. iconv(), UConverter class and
> mb_convert_encoding().

I'm afraid that's too easily overlooked.  Actually, nobody who knows the
working of utf8_(en|de)code would even have a look at its man page,
particularly, if they're not working on the code that uses these functions.

Anyhow, actually I think that utf8_(en|de)code are not the real problem,
but rather the complete XML extension is.  xml_set_object() causes
memory issues which have to be handled in userland[1],
xml_parse_into_struct() is more than doubtful[2] and the whole concept
of attaching callbacks manually (instead of extending a base class) is
so clumsy[3].

Furthermore the extension is basically without active maintainer.  Thies
made his last commit in 2002, and Rob made only 1 bugfix since 2010,
even though there are several unresolved issues[4].

Unless a new active maintainer steps forward, we should consider to move
ext/xml to PECL, in which case the deprecation of utf8_(en|de)code might
be unnecessary.

[1] <http://news.php.net/php.internals/94998>
[2] <http://news.php.net/php.internals/95033>
[3] <http://news.php.net/php.internals/95018>
[4]
<https://bugs.php.net/search.php?cmd=display&bug_type=All&status=Open&package_name%5B%5D=%2AXML+functions&by=Any&limit=30>

-- 
Christoph M. Becker