On Tue, 2014-10-21 at 13:52 +0400, Dmitry Stogov wrote: > > > 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 :)
You must like punishment :D > > 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. > The implementation might be simpler, but the effect the same I think. I can be wrong, but nothing has so drastically changed that will allow us to absorb the kind of impact I think you are talking about. > > > 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? Totally possible that we'll have to change, or that we should change. A few people have said they would like to write a backend so we'll see what comes in and where that leads us. > > 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 Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
