Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84442 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26625 invoked from network); 8 Mar 2015 17:52:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Mar 2015 17:52:07 -0000 X-Host-Fingerprint: 78.217.8.218 gaz43-2-78-217-8-218.fbx.proxad.net Received: from [78.217.8.218] ([78.217.8.218:20346] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B8/C6-17427-54C8CF45 for ; Sun, 08 Mar 2015 12:52:06 -0500 To: internals@lists.php.net,Lester Caine Message-ID: <54FC8C41.40104@luni.fr> Date: Sun, 08 Mar 2015 18:52:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <54F83C4D.1020206@gmail.com> <54FB3175.3000308@luni.fr> <54FC1E67.3070504@luni.fr> <54FC2FC1.9070008@lsces.co.uk> <54FC5465.10208@luni.fr> <54FC708E.90007@lsces.co.uk> In-Reply-To: <54FC708E.90007@lsces.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 78.217.8.218 Subject: Re: [PHP-DEV] Consistent function names From: gregory@luni.fr (=?UTF-8?B?R3LDqWdvcnkgUGxhbmNoYXQ=?=) Le 08/03/2015 16:53, Lester Caine a écrit : >> "Lorem ipsum dolor sit amet"->length(); >> "Lorem ipsum dolor sit amet"->search('lorem'); >> "Lorem ipsum dolor sit amet"->replace('lorem', 'Lorem'); > > This is actually the problem that trying to ignore unicode then creates > a black hole. The amount of space needed to store the string is a > variable once one moves outside the single byte encodings, but where > legacy systems only allow buffering for the single byte version, one > gets a number of problems where the data returned has multi-byte > characters. The first example has several answers depending on what one > is doing with the return. Size of buffer needed (sizeof in my crib > sheet), or one of the methods of counting the number of symbols used > (count but with an agreed decoding). The other two actually work with > multi-byte strings until one adds 'adornments' to the characters which > may need a search to look for a set of similar words all with the same > meaning, just encoded differently. > > My point is perhaps that it is all to easy nowadays or post/get data to > have multi-byte strings from different languages which trying to map to > a single byte solution is no longer appropriate. I've just been > downloading a set of documents which are essentially all English, but > the file names includes words from a number of other languages resulting > in UTF8 being the only way to store them, and ideally the search engine > should be able to find them again in the future. > I understand your point, but what I mean is not making the user totally unaware of the encoding, but building a common API to make it easier for everyone to avoid the need of permanent awareness, anywhere, anytime of the encoding. Instead, make the string API make the job of choosing whichever backend extension is used (default or mbstring), then if the user feels the need of mixing encodings, he *SHOULD* have to be aware of it *AND* have the right transformations API availiable. This is to make possible to simply build methods that do not need to be aware of encoding (eg. pure frontend text treatments) to automatically map to the right encoding (maybe with E_RECOVERABLE_ERROR on incompatible charsets). Maybe string notations could also evolve, such as what exists in C for wchar_t strings (like some L prefix, or else), I have no fixed opinions about that and it is not the main subject anyway. The main question is about an uniform API for strings, do you feel it is important/useful or not? Grégory Planchat