Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78188
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.47 cause and error)
Message-ID: <1413883549.2624.22.camel@localhost.localdomain>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP Internals <internals@lists.php.net>
Date: Tue, 21 Oct 2014 10:25:49 +0100
In-Reply-To: <CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com>
References: <1413875212.2624.3.camel@localhost.localdomain>
	 <CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] UString
From: pthreads@pthreads.org (Joe Watkins)

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 ?

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.

> 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.
> 
> 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