Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85963 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21718 invoked from network); 27 Apr 2015 09:03:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Apr 2015 09:03:16 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; 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:56078] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 56/74-17556-25BFD355 for ; Mon, 27 Apr 2015 05:03:15 -0400 Received: (qmail 7501 invoked by uid 89); 27 Apr 2015 09:03:10 -0000 Received: by simscan 1.3.1 ppid: 7490, pid: 7498, t: 0.2334s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 27 Apr 2015 09:03:10 -0000 Message-ID: <553DFB4D.1090109@lsces.co.uk> Date: Mon, 27 Apr 2015 10:03:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: internals@lists.php.net References: <553DBEC4.7000609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7 From: lester@lsces.co.uk (Lester Caine) On 27/04/15 09:15, Benjamin Eberlei wrote: >> There was a lot of discussion about this topic. Right now, unless >> > there's a proposal to fix it that works, I don't see what can be done >> > about it. >> > > It should be possible to write something with PHP Parser detecting all the > occurances of "String/string" class usage to at least give a worklog of > entries that need to be changed, or maybe generate a patch file that can be > applied to the code base after review. We have already had a similar incidence of this problem with the date/time stuff. The main problem then was it being introduced at the wrong time. PHP7 is the right time but switching the names being use is not an option. string IS probably the most difficult one, but any good IDE will allow all of the existing names to be changed. What is possibly an annoyance here is that this IS simply blocking the usage, rather than providing a functional replacement? Other 'priorities' seem to have pushed a single string handling solution back down the pile :( The question should perhaps be does any of the third part string classes provide a 'pear' style alternative which can be later be converted to an internal function set? -- 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