On Tue, Oct 21, 2014 at 1:25 PM, Joe Watkins <pthre...@pthreads.org> wrote:
> On Tue, 2014-10-21 at 13:01 +0400, Dmitry Stogov wrote: > > Hi Joe, > > > > > > As an extension it looks fine. > > > > I assume, you don't propose to use UString objects in engine and other > > extensions. > > I'm not proposing it now, no. > > > Unfortunately, it's yet another incomplete solution. > > > > It won't allow Unicode strings as array keys; > > The engine doesn't allow that, couldn't we find a way of using objects > as array keys ?? It doesn't seem like a limitation of the extension, to > me ;) > > > concatenation using "." (probably may be done), > > That's already done. > > > no auto-conversion from/to script/output encoding, > > That could be arranged. > > > no auto-conversion of strings coming from database extensions, etc > > I'm not sure how important that is, it's not a big deal to create a new > object, nor would it be a big deal for those extensions that need to > always return unicode strings to do so. > > > > The "right" approach, would be extending zend_string with "encoding" > > and then adopting near all functions working with zend_string to take > > "encoding" into account. But, of course, this is going to lead to much > > more complicated solution (with some slowdown). > > That seems a lot like bashing our head against a wall. We tried to > introduce support everywhere and it fails. Do we really want to step on > the performance gains introduced by recent changes by making all strings > unicode ? > Yeah :) I'm not sure, if it should be done, and I don't like to work on it in the nearest future, but zend_string approach should be easier to implement than separate IS_UNICODE + IS_STRING + IS_BINARY types in PHP6. > That doesn't seem like a sensible thing to want, at least right now. > > Having UString doesn't stop us approaching the problem differently in > the future, but it would have to be a very different future to even make > sense to me. > Agree. > > > If we don't care about complete solution, UString proposal may make > > sense at lest as a faster replacement of ext/mbstring. > > As the RFC states, we are only approaching one problem, the problem that > ext/mbstring is not a good API. > Then, it's fine. One note regarding implementation: why do you use C++ for ustring.cpp? I understand it's necessary for ICU backend, but if in the future you might switch to another backend (and it may not require C++) why to use C++ for PHP extension part? Thanks. Dmitry. > > > > Thanks. Dmitry. > > > > On Tue, Oct 21, 2014 at 11:06 AM, Joe Watkins <pthre...@pthreads.org> > > wrote: > > Morning internalz, > > > > 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 ;) > > > > Cheers > > Joe > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > Cheers > Joe > >
