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....@gmail.com> wrote:
On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins <pthre...@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
