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