Morning Sara,
> 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 was (semi) convinced by Dmitry that the superior implementation is one
for Zend, so I backed off ...
> 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.
The folder the source code is in makes no nevermind, the real issue with
integration
is changing all of intl, and lots of other stuff, to accept UString, since
casting to basic type
, while acceptable for simple tests, would get extremely wasteful for an
application of any complexity.
Another possible issue is engine integration:
$string = (UString) $someString;
$string = (UString) "someString";
These aren't very different to 'new UString', but for an integrated
solution, kind of expected to work.
I don't know what the solutions are to these problems, I'm all ears ...
Cheers
Joe
On Wed, Jul 1, 2015 at 12:30 AM, Sara Golemon <poll...@php.net> 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
>
