Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78192
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.212.169 cause and error)
Message-ID: <1413886401.2624.33.camel@localhost.localdomain>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP Internals <internals@lists.php.net>
Date: Tue, 21 Oct 2014 11:13:21 +0100
In-Reply-To: <CA+9eiLtgP91eAPCS8vh+A2sijKhX8-sCKyU4axCDxbpLEcfkYw@mail.gmail.com>
References: <1413875212.2624.3.camel@localhost.localdomain>
	 <CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com>
	 <1413883549.2624.22.camel@localhost.localdomain>
	 <CA+9eiLtgP91eAPCS8vh+A2sijKhX8-sCKyU4axCDxbpLEcfkYw@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:52 +0400, Dmitry Stogov wrote:
> 
> 
> 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 :)

You must like punishment :D
> 
> 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.
> 
The implementation might be simpler, but the effect the same I think.

I can be wrong, but nothing has so drastically changed that will allow
us to absorb the kind of impact I think you are talking about.

>  
> 
>         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? 

Totally possible that we'll have to change, or that we should change. A
few people have said they would like to write a backend so we'll see
what comes in and where that leads us.


> 
> 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


Cheers
Joe