Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78225
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com>
References: <1413875212.2624.3.camel@localhost.localdomain>
	<CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com>
Date: Wed, 22 Oct 2014 16:05:50 +0700
Message-ID: <CAEZPtU5s+KYcNtAvBkuPUYwV+xxpteBRG8Y0aOjvGQsYW-LA0w@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.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)

hi,

On Tue, Oct 21, 2014 at 4:01 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> Hi Joe,
>
> As an extension it looks fine.
> I assume, you don't propose to use UString objects in engine and other
> extensions.
> Unfortunately, it's yet another incomplete solution.

I have to agree here.

As much as I like what has been done here, having UString as part of
the engine or at least main/ may help tighter integration. I am also
not sure about the driver approach (have to double check it again as I
stopped following it since a couple of weeks). Having UString in the
core is a great thing anyway. However there is no mention whether it
should be always enabled or not. I think it should be always enabled,
providing the base Unicode strings features by default. Having ICU as
default dependency is not really an issue imho.

We discussed that with Joe in the early UString days but we did not
agree. Mainly because he likes to keep UString independent, unbloated
etc. I think it is possible to keep it simple and having it tightly
integrated in the core. Advanced features can be done either in intl
or in userland (if we can avoid having every single project doing its
own unicode string class... that would keep the performance
improvement along other annoying APIs differences).

> It won't allow Unicode strings as array keys;
> concatenation using "." (probably may be done),
> no auto-conversion from/to script/output encoding,
> no auto-conversion of strings coming from database extensions, etc
>
> 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).

Fully agree here too.

> If we don't care about complete solution, UString proposal may make sense
> at lest as a faster replacement of ext/mbstring.

I agree here too. For one I do care about a complete solution, for the
basic Unicode features, integrated with the language.

> Thanks. Dmitry.
>
>
>
> On Tue, Oct 21, 2014 at 11: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 ;)
>>
>> Cheers
>> Joe
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>



-- 
Pierre

@pierrejoye | http://www.libgd.org