Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78190
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1413883549.2624.22.camel@localhost.localdomain>
References: <1413875212.2624.3.camel@localhost.localdomain>
	<CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com>
	<1413883549.2624.22.camel@localhost.localdomain>
Date: Tue, 21 Oct 2014 13:52:19 +0400
Message-ID: <CA+9eiLtgP91eAPCS8vh+A2sijKhX8-sCKyU4axCDxbpLEcfkYw@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c30fbc78e8c60505ebc9aa
Subject: Re: [PHP-DEV] [RFC] UString
From: dmitry@zend.com (Dmitry Stogov)

--001a11c30fbc78e8c60505ebc9aa
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 21, 2014 at 1:25 PM, Joe Watkins <pthreads@pthreads.org> wrote:

> On Tue, 2014-10-21 at 13:01 +0400, Dmitry Stogov wrote:
> > Hi Joe,
> >
> >
> > As an extension it looks fine.
> >
> > I assume, you don't propose to use UString objects in engine and other
> > extensions.
>
> I'm not proposing it now, no.
>
> > Unfortunately, it's yet another incomplete solution.
> >
> > It won't allow Unicode strings as array keys;
>
> The engine doesn't allow that, couldn't we find a way of using objects
> as array keys ?? It doesn't seem like a limitation of the extension, to
> me ;)
>
> > concatenation using "." (probably may be done),
>
> That's already done.
>
> > no auto-conversion from/to script/output encoding,
>
> That could be arranged.
>
> > no auto-conversion of strings coming from database extensions, etc
>
> I'm not sure how important that is, it's not a big deal to create a new
> object, nor would it be a big deal for those extensions that need to
> always return unicode strings to do so.
> >
> > 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).
>
> That seems a lot like bashing our head against a wall. We tried to
> introduce support everywhere and it fails. Do we really want to step on
> the performance gains introduced by recent changes by making all strings
> unicode ?
>

Yeah :)
I'm not sure, if it should be done, and I don't like to work on it in the
nearest future, but zend_string approach should be easier to implement than
separate IS_UNICODE + IS_STRING + IS_BINARY types in PHP6.


> That doesn't seem like a sensible thing to want, at least right now.
>
> Having UString doesn't stop us approaching the problem differently in
> the future, but it would have to be a very different future to even make
> sense to me.
>

Agree.


>
> > If we don't care about complete solution, UString proposal may make
> > sense at lest as a faster replacement of ext/mbstring.
>
> As the RFC states, we are only approaching one problem, the problem that
> ext/mbstring is not a good API.
>

Then, it's fine.

One note regarding implementation: why do you use C++ for ustring.cpp? I
understand it's necessary for ICU backend, but if in the future you might
switch to another backend (and it may not require C++) why to use C++ for
PHP extension part?

Thanks. Dmitry.


> >
> > 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
>
> Cheers
> Joe
>
>

--001a11c30fbc78e8c60505ebc9aa--