Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78273
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <5449064E.5020303@gmail.com>
Date: Thu, 23 Oct 2014 14:52:41 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <17F21E0F-2D33-4290-806A-70159E529F15@ajf.me>
References: <1413875212.2624.3.camel@localhost.localdomain> <CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com> <5449064E.5020303@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] UString
From: ajf@ajf.me (Andrea Faulds)


> On 23 Oct 2014, at 14:44, Rowan Collins <rowan.collins@gmail.com> =
wrote:
>=20
> Dmitry Stogov wrote on 21/10/2014 10:01:
>> The "right" approach, would be extending zend_string with "encoding" =
and
>> then adopting near all functions working with zend_string to take
>> "encoding" into account. But, of course, this is going to lead to =
much more
>> complicated solution (with some slowdown).
>=20
> Isn't that kind of what ext/mbstring does?
>=20
> I think that treating Unicode as nothing more than an encoding, and =
trying to hide all its complexity from the user, is not particularly =
wise. Unicode isn't just "ASCII, but bigger", so keeping the same API =
but making the implementation "work" with more characters isn't really =
"Unicode support=E2=80=9D.

I=E2=80=99m inclined to agree here. Having an encoding-aware zend_string =
vs. having a Unicode-aware string aren=E2=80=99t quite the same. Certain =
string operations are only possible for certain encodings, and by =
supporting any encoding we risk making things confusing. I=E2=80=99d =
rather we convert everything to Unicode.
--
Andrea Faulds
http://ajf.me/