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