Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86998
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 217.70.183.197 cause and error)
To: internals@lists.php.net
References: <1413875212.2624.3.camel@localhost.localdomain>
 <CAF+90c_RhEYvFrQ7Vs+2eSsLR+_rf8D_3W6Ao0M_e5iC6iPqFA@mail.gmail.com>
 <CAESVnVquViA2SHErqPih-aqFjBVQqcO+wazhczL77wWShEWHBA@mail.gmail.com>
Message-ID: <55953FE5.3070102@hoa-project.net>
Date: Thu, 2 Jul 2015 15:43:01 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CAESVnVquViA2SHErqPih-aqFjBVQqcO+wazhczL77wWShEWHBA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] UString
From: ivan.enderlin@hoa-project.net ("\"Ivan Enderlin\"@Hoa")

Hello :-),

Just a small detail. Please, choose another name. The `Hoa\String` 
https://packagist.org/packages/hoa/string library has been renamed to 
`Hoa\Ustring` because of PHP7. So, please, don't force us to rename the 
library again ;-).

Moreover, this library provides an API that is useful for daily use and 
can be inspiring. Please, see 
http://hoa-project.net/Literature/Hack/Ustring.html.

Regards.

On 01/07/15 01:30, Sara Golemon wrote:
> On Mon, Mar 2, 2015 at 12:48 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
>> On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins <pthreads@pthreads.org> wrote:
>>>          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 ;)
>>>
> Curious what the current state of the UString RFC is.  I've got a
> functionality request for HHVM to wrap icu::UnicodeString and was
> hoping to match PHP behavior if any plans had been made, and lo...
> here's a plan!
>
>> I'm not totally convinced by this proposal. We already have quite a number
>> of extensions that deal with unicode text in one way or another (at least
>> intl, mbstring and iconv). This adds yet another way of dealing with this
>> issue - a way that will have to be combined with at least two other
>> extensions (mbstring or iconv for input handling and conversion) and intl
>> for any non-trivial operations. There's nothing wrong with adding another
>> approach for unicode handling per se, but I'd like to have more empahsis on
>> how this integrates with existing functionality and why it is implemented
>> separately from it (especially intl), etc.
>>
> I think (hope) that Joe's intention was to make it as an extension for
> proof of concept, but make it part of the intl extension when it comes
> to full adoption by the runtime.  If not, let's talk about making that
> the intent, because intl is where this belongs.
>
> For my bikeshedding part, I'd recommend against the u() function
> helper as it pollutes the global function namespace and takes a very
> fundamental name.  intl\u() might be worth considering, but we'll need
> to have a discussion about namespacing for the intl extension as a
> whole (separate topic).
>
> I'd also recommend "IntlString" rather than "UString" as nearly all
> the Intl classes follow this convention.  The one notable exception
> being UConverter (which yes, I added, and I regret the departure in
> naming).
>
> Otherwise, while there's room to quibble about specific API names and
> arguments, the general concept seems a no-brainer.
>
> -Sara
>