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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php