Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71177 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4445 invoked from network); 16 Jan 2014 11:06:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Jan 2014 11:06:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.180 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.217.180 mail-lb0-f180.google.com Received: from [209.85.217.180] ([209.85.217.180:39891] helo=mail-lb0-f180.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 91/92-24763-F2DB7D25 for ; Thu, 16 Jan 2014 06:06:24 -0500 Received: by mail-lb0-f180.google.com with SMTP id n15so1735729lbi.39 for ; Thu, 16 Jan 2014 03:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=MBdS7I5c24KYIaZoeNCq8zhiroYEjXLfRRoErPUx+sc=; b=uy0L9NzD4BWxQ+LHY/ICa+mpPDjlAyQG0PA20HmNcABRxJ/AjFCnMcVwnSAAhkrbje 83MUN5ZLiPkVkDgZqxbJ6SyPBVOnYGj5d3W3cujNj5AYnddw5zYhdAjCCFy1Ig8fNNia Ju8cel+2ZEvFUBzmyBZ9yYhV69q3TovV6hWcqjrW3mIspouzL7l3ihDH7w+OlU6l4EWJ /PUd3qiKj54LsOtcKM6+Uf7JznZWQ1uaDc5+lRKywdYFbZU8ohmHBAZiYMKJKYqSDHGB jn131zFVMERv7WpdzVY25ICA7tjp1/xNICDY4A99ZD91VH8PcrW+Zk2YFQM+iL9J+N7U S2rg== X-Received: by 10.112.140.66 with SMTP id re2mr549347lbb.48.1389868614252; Thu, 16 Jan 2014 02:36:54 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.112.6.68 with HTTP; Thu, 16 Jan 2014 02:36:14 -0800 (PST) In-Reply-To: <52D7889D.4010705@sugarcrm.com> References: <20140116023616.A43BF26437F@dd15934.kasserver.com> <52D7889D.4010705@sugarcrm.com> Date: Thu, 16 Jan 2014 19:36:14 +0900 X-Google-Sender-Auth: uF7cwJIFBD3C-48ZiiCco4thrqk Message-ID: To: Stas Malyshev Cc: "mails@thomasbley.de" , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a11c38b1c097d5b04f01401a7 Subject: Re: [PHP-DEV] Re: [RFC] Multibyte char handling From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11c38b1c097d5b04f01401a7 Content-Type: text/plain; charset=UTF-8 Hi Stas, On Thu, Jan 16, 2014 at 4:22 PM, Stas Malyshev wrote: > > We need few more basic functions like trim(). > > This is different issue, but I may work on it. > > It feels like we will end up with creating clones of pretty every string > function there is. Not sure it is the best approach... We could learn from Python 2.x and 3.x. There are Python users, who are serious about multilingual support, complain about 3.x. They insist 2.x behavior and even want to discontinue 3.x. I don't think mbstring is optimum multibyte string library neither. We may keep current structure until we have decent multibyte string library that could live long enough. By the time we have it, we may use compatibility switch for basic string functions to change multibyte awareness. If we are going to choose this way, it may be better to have byte_len() and other byte_*() function now for easier transition. I'm not sure which is the best having mb_*(), byte_*() or specifying binary encoding for standard string functions, though. It's out of this RFC scope. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a11c38b1c097d5b04f01401a7--