Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87000
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.196 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>
 <55953FE5.3070102@hoa-project.net> <559540C9.8030504@heigl.org>
Message-ID: <55954115.8030904@hoa-project.net>
Date: Thu, 2 Jul 2015 15:48:05 +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: <559540C9.8030504@heigl.org>
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")

I fear it will be a reserved keyword.

On 02/07/15 15:46, Andreas Heigl wrote:
> Hi.
>
> Am 02.07.15 um 15:43 schrieb "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 ;-).
> What's the issue with the name?
>
> As far as I see it, There's no problem at all, as there's UString and
> then there's Hoa\UString. Different namespace, no issue.
>
> Or am I missing something?
>
> Cheers
>
> Andreas
>
>> 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
>>>
>>
>