Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78261
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.212.174 cause and error)
Message-ID: <1414052597.2624.44.camel@localhost.localdomain>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Date: Thu, 23 Oct 2014 09:23:17 +0100
In-Reply-To: <544697DA.6010506@sugarcrm.com>
References: <1413875212.2624.3.camel@localhost.localdomain>
	 <544697DA.6010506@sugarcrm.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] UString
From: pthreads@pthreads.org (Joe Watkins)

On Tue, 2014-10-21 at 10:28 -0700, Stas Malyshev wrote:
> Hi!
> 
> > 	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.
> 
> Couple of thoughts:
> - I like the idea of having a unicode string class. May be a way to
> figure out the right way to do it without messing up the whole core.
> 
> - I wish there were more description of which API this class provides.
> If it's planned to be direct copy of UnicodeString, some of the
> operations there are not how PHP strings usually work (i.e. in-place
> modification) and it's not really enough to make it useful - e.g. what
> if I need to do regexps on it, for example? Or does it cover whole
> mbstring API too? What about something mbstring doesn't cover, like
> ucfirst or strrev?

API on github in readme.

Regexp not covered yet, ICU has a nicer Matcher/Pattern API like Java's,
I'm not sure what to do there, an ICU based API could certainly be
introduced.
> 
> - Do we really need different encodings, different backends and so on,
> internally? Note that each backend has its own quirks, limitations and
> bugs, and there's nothing worse than dealing with unpredictable set of
> dependencies. The user cares what they send into the class and what
> comes out, but very rarely they care what happens inside - why not just
> do it one way everywhere?
> 

No, actually, I don't think we do. It was over complicating something
simple, so I removed the backend abstraction and will work towards
solving the rest too.

We'll use ICU, because battle tested like nothing else, and keeps
everything simple ... it doesn't make sense to introduce a possibly
unstable and as you rightly say different API with it's own quirks.

Cheers
Joe