Hi. Am 02.07.15 um 15:43 schrieb "Ivan Enderlin"@Hoa: > Hello :-), > > Just a small detail. Please, choose another name. The `Hoa\String` > https://packagist.org/packages/hoa/string library has been renamed to > `Hoa\Ustring` because of PHP7. So, please, don't force us to rename the > library again ;-).
What's the issue with the name? As far as I see it, There's no problem at all, as there's UString and then there's Hoa\UString. Different namespace, no issue. Or am I missing something? Cheers Andreas > > Moreover, this library provides an API that is useful for daily use and > can be inspiring. Please, see > http://hoa-project.net/Literature/Hack/Ustring.html. > > Regards. > > On 01/07/15 01:30, Sara Golemon wrote: >> On Mon, Mar 2, 2015 at 12:48 AM, Nikita Popov <nikita....@gmail.com> >> wrote: >>> On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins <pthre...@pthreads.org> >>> wrote: >>>> 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 ;) >>>> >> Curious what the current state of the UString RFC is. I've got a >> functionality request for HHVM to wrap icu::UnicodeString and was >> hoping to match PHP behavior if any plans had been made, and lo... >> here's a plan! >> >>> I'm not totally convinced by this proposal. We already have quite a >>> number >>> of extensions that deal with unicode text in one way or another (at >>> least >>> intl, mbstring and iconv). This adds yet another way of dealing with >>> this >>> issue - a way that will have to be combined with at least two other >>> extensions (mbstring or iconv for input handling and conversion) and >>> intl >>> for any non-trivial operations. There's nothing wrong with adding >>> another >>> approach for unicode handling per se, but I'd like to have more >>> empahsis on >>> how this integrates with existing functionality and why it is >>> implemented >>> separately from it (especially intl), etc. >>> >> I think (hope) that Joe's intention was to make it as an extension for >> proof of concept, but make it part of the intl extension when it comes >> to full adoption by the runtime. If not, let's talk about making that >> the intent, because intl is where this belongs. >> >> For my bikeshedding part, I'd recommend against the u() function >> helper as it pollutes the global function namespace and takes a very >> fundamental name. intl\u() might be worth considering, but we'll need >> to have a discussion about namespacing for the intl extension as a >> whole (separate topic). >> >> I'd also recommend "IntlString" rather than "UString" as nearly all >> the Intl classes follow this convention. The one notable exception >> being UConverter (which yes, I added, and I regret the departure in >> naming). >> >> Otherwise, while there's room to quibble about specific API names and >> arguments, the general concept seems a no-brainer. >> >> -Sara >> > > -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+
smime.p7s
Description: S/MIME Cryptographic Signature
