Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79151 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52431 invoked from network); 25 Nov 2014 10:01:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2014 10:01:01 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:46924] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3E/81-40624-85354745 for ; Tue, 25 Nov 2014 05:01:00 -0500 Received: (qmail 12407 invoked by uid 89); 25 Nov 2014 10:00:22 -0000 Received: by simscan 1.3.1 ppid: 12315, pid: 12342, t: 2.2244s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.178.188.220) by mail4.serversure.net with ESMTPA; 25 Nov 2014 10:00:20 -0000 Message-ID: <54745321.9020507@lsces.co.uk> Date: Tue, 25 Nov 2014 10:00:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions From: lester@lsces.co.uk (Lester Caine) On 25/11/14 04:47, Sara Golemon wrote: > While playing around with Andrea's unicode literals syntax proposal, I > was reminded of just how little of ICU is exposed. I've put up a > short proposal for adding IntlChar exporting these APIs as static > methods (with a matching non-oop interface). > > https://wiki.php.net/rfc/intl.char Isn't the problem here that while ICU is perhaps the obvious way forward, there is still no decision that it will be the base for other developments? Other proposals are looking for a lighter solution to the problem? I'd make a case for using the UTF8 configuration of ICU as the base for all the unicode developments, but can understand that this may not play well with other installations of ICU on a system? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk