Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95367
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
References: <CAGa2bXYGUhihdbMMBQB7FQ6CnmYqrB_x2YVjdZTvT8gDs59oOQ@mail.gmail.com>
 <CAEZPtU7Zq=RpNMYz6dRCaiUVLFf4S68MOQHxPFVBsWaRZu9cJQ@mail.gmail.com>
 <ac86fed5-56b5-84d0-d54d-95cce8f36c2d@gmail.com>
 <CAGa2bXYBLCROkv+BBm4DoyJz=S5uMdqttAmWGE2YiHJpRribHQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <8f77da79-e843-aee0-e68d-e132ada5e782@gmail.com>
Date: Mon, 22 Aug 2016 11:44:27 +0100
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: <CAGa2bXYBLCROkv+BBm4DoyJz=S5uMdqttAmWGE2YiHJpRribHQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and
 utf8_encode()
From: rowan.collins@gmail.com (Rowan Collins)

On 22/08/2016 02:52, Yasuo Ohgaki wrote:
> Since these
> are XML module functions, the name would be xml_latin1_to_utf8() and
> xml_utf8_to_latin1(). Suggestions for names are appreciated.

 From a user's point of view, these functions have nothing to do with 
XML, so I'm not sure the prefix really makes sense. I had no idea until 
a few days ago that they were in the same extension in the source, and I 
suspect most users aren't even aware that "built-in" functions like this 
are arranged in "extensions" at all.

The naming convention in CODING_STANDARDS [1] doesn't actually make 
reference to extensions, only a "parent set", so I don't think "xml_" is 
a mandatory or natural prefix according to that rule.

[1] https://github.com/php/php-src/blob/master/CODING_STANDARDS

As far as I can see, these functions exist because the XML parser 
infrastructure needed them, and someone thought it might be handy to 
expose them to users. Funnily enough, the internal versions actually 
take a parameter for the target encoding, but only support US-ASCII and 
8859-1: https://github.com/php/php-src/blob/master/ext/xml/xml.c#L283

If anything, they should probably have a "str_" prefix, and maybe even 
be moved into the string section of the source, exposed in such a way 
that the XML parser can still make use of them.

Regards,
-- 
Rowan Collins
[IMSoP]