Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78175
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1413875212.2624.3.camel@localhost.localdomain>
References: <1413875212.2624.3.camel@localhost.localdomain>
Date: Tue, 21 Oct 2014 08:40:57 +0100
Message-ID: <CAPwsocForNg2B5We=iEgS6pChTg4cX4qeHbMTL4KqSaW0apd8A@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] UString
From: leight@gmail.com (Leigh)

On 21 October 2014 08:06, 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 ;)
>

Breaks nothing, faster than mbstring, seems like win/win to me.

> On the flip side, implementing UString as a scalar object would be inconsistent. At time of writing, array, int, float, bool, etc have no implementation available for this.

I agree it shouldn't be a scalar object, but how about some operator
overloading like the GMP object has, so that you don't have to cast to
string for expected behaviour with type coercion etc.

> Right now there are user-space libraries out there that cover a lot more functionality than UString.

Do you need help implementing these? Do you think it would be
beneficial to briefly list which areas need attention on the RFC, so
they can be checked off over time?

Overall +1 on the concept.