Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67561
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADajX4BPRNv-AS4PKgR2+DBW9DfFJf1w4ij278CjKiWJ_gywhw@mail.gmail.com>
References: <61BC4F17-86D9-4CBD-B185-58A2D4AFAE5F@rouvenwessling.de>
	<CAF+90c__m2zsi9ag32TAP+2yCFOj8gf_z4oNUxEoNCsJi-K1OQ@mail.gmail.com>
	<CAH-PCH4w2YTwvHdPFFC-TygSBQpssv6woQJaoa3JVks1egq44g@mail.gmail.com>
	<CADajX4BR_YA6y7UB-nqr=c9dJo-nprw2pYfOh+UmeT-kr1nRCA@mail.gmail.com>
	<51A2DB98.6020501@sugarcrm.com>
	<CADajX4BPRNv-AS4PKgR2+DBW9DfFJf1w4ij278CjKiWJ_gywhw@mail.gmail.com>
Date: Mon, 27 May 2013 20:04:07 +0200
Message-ID: <CAEZPtU7kFPNgZR+yfNTWYq1Ab2=oa2K_mc_yDOJiANy+TkyjGQ@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Proposal for better UTF-8 handling
From: pierre.php@gmail.com (Pierre Joye)

hi Adam!

On Mon, May 27, 2013 at 6:39 PM, Adam Harvey <aharvey@php.net> wrote:
> On 26 May 2013 21:05, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>>
>>> I agree with Nikita =97 I'm not against adding more Unicode/charset
>>> handling functions if they make sense (and I haven't looked at the
>>> code for this particular proposal yet), particularly if they'd be part
>>> of a default build, but enough water has hopefully passed under the
>>
>> Did you mean "would *not* be part of the default build"? Because having
>> yet another way of handling utf-8 (also basing on yet another separate
>> library so with potential for incompatibilities and quirks) doesn't look
>> like a good idea. Having yet another PECL ext is not a big deal, but
>> having yet another way by default certainly would only create confusion.
>
> I did mean would =97 one issue with much of our internationalisation
> code is that it's in extensions (intl, iconv, mbstring) that are
> inconsistently deployed by shared hosting providers. Having some basic
> conversion and string handling functions that could be available in
> ext/standard might not be a bad thing.

We will still require to use some external Unicode data. I won't go
with our own data set, ever, that's something we won't be able to
maintain. By the way, it is why intl is very good, same APIs, it only
adds new functions, no change in existing APIs, but you get free
Unicode data update while updating the library. And I would like to
enable it by default, or make it a required extension at some point.


Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org