Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84153
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1413875212.2624.3.camel@localhost.localdomain>
References: <1413875212.2624.3.camel@localhost.localdomain>
Date: Mon, 2 Mar 2015 09:48:20 +0100
Message-ID: <CAF+90c_RhEYvFrQ7Vs+2eSsLR+_rf8D_3W6Ao0M_e5iC6iPqFA@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb04ee4c3a2d905104a478e
Subject: Re: [PHP-DEV] [RFC] UString
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bb04ee4c3a2d905104a478e
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins <pthreads@pthreads.org> wrote:

> Morning internalz,
>
>         https://wiki.php.net/rfc/ustring
>
>         This is the result of work done by a few of us, we won't be
> opening any
> vote in a fortnight. We have a long time before 7, there is no rush
> whatever.
>
>         Now seems like a good time to start the conversation so we can
> hash out
> the details, or get on with other things ;)
>

I'm not totally convinced by this proposal. We already have quite a number
of extensions that deal with unicode text in one way or another (at least
intl, mbstring and iconv). This adds yet another way of dealing with this
issue - a way that will have to be combined with at least two other
extensions (mbstring or iconv for input handling and conversion) and intl
for any non-trivial operations. There's nothing wrong with adding another
approach for unicode handling per se, but I'd like to have more empahsis on
how this integrates with existing functionality and why it is implemented
separately from it (especially intl), etc.

On a more general note, I'd appreciate it if RFCs proposing the inclusion
of extensions moved more of their content into the actual RFC, as opposed
to being thin wrappers around the extension README/docs. We had this issue
with the pecl_http RFC and the same applies here. I think the suggested API
is a pretty important aspect of the proposal and as such should be included
in the RFC and maybe also commented a bit ;)

Nikita

--047d7bb04ee4c3a2d905104a478e--