Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84154
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c_RhEYvFrQ7Vs+2eSsLR+_rf8D_3W6Ao0M_e5iC6iPqFA@mail.gmail.com>
References: <1413875212.2624.3.camel@localhost.localdomain>
	<CAF+90c_RhEYvFrQ7Vs+2eSsLR+_rf8D_3W6Ao0M_e5iC6iPqFA@mail.gmail.com>
Date: Mon, 2 Mar 2015 00:58:27 -0800
Message-ID: <CAEZPtU4ruvsXc7eEZRw2rZZ1uARtbcn=-M+S8Pxo3uh5LZS=Nw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Joe Watkins <pthreads@pthreads.org>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] UString
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Mar 2, 2015 at 12:48 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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 ;)

Full ack. Both paragraph.

As of now, and based on the previous discussions pointed out the same
issues (minus the RFC one, but this is a detail, important, but a
detail), I am also not convinced this is the way to tackle the Unicode
text support. It should either be part of intl (and proposed to enable
intl always for 7, with other RFC) or main. Main has the advantage to
provide a easier integration with other extensions.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org