Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100622 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 7372 invoked from network); 15 Sep 2017 12:31:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Sep 2017 12:31:08 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain lsces.co.uk designates 185.153.204.204 as permitted sender) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 185.153.204.204 mail4.serversure.net Linux 2.6 Received: from [185.153.204.204] ([185.153.204.204:43820] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DC/4D-19300-908CBB95 for ; Fri, 15 Sep 2017 08:31:07 -0400 Received: (qmail 5383 invoked by uid 89); 15 Sep 2017 12:31:02 -0000 Received: by simscan 1.3.1 ppid: 5377, pid: 5380, t: 0.0444s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 15 Sep 2017 12:31:02 -0000 To: internals@lists.php.net References: <3D.0C.10715.383F8B95@pb1.pair.com> <20b8b6fa-ec81-eba9-d33b-b54b815e9e5d@lsces.co.uk> <88.FC.19300.2418AB95@pb1.pair.com> <20170914133846.GQ8096@phcomp.co.uk> <1E.C8.19300.EA49BB95@pb1.pair.com> Message-ID: Date: Fri, 15 Sep 2017 13:31:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants? From: lester@lsces.co.uk (Lester Caine) On 15/09/17 12:13, Tony Marston wrote: > My argument is that far too many people have become used to case > insensitive software, and to remove this "feature" for no other reason > than the programmers involved would find it "more convenient" to remove > the feature altogether rather than make the effort in implementing a > proper solution would go down like a ton of bricks with all those users. case-insensitive only works reliably for an ascii character set. This is what the vast majority of PROGRAMMERS expect to see. Even Microsoft 16bit subset of unicode characters can not RELIABLY be upper or lower cased, but add the full unicode set and the conflicts of the number of characters required for one or other conversion explains why a conversion to unicode in the core proved impractical. The main point here is that it may be ESSENTIAL to introduce a switch to case sensitive if we are also to convert to full unicode support. The alternative is to restrict the character set back to ascii for all programming operations if case-insensitivity is to be retained. And how many of you have hit the problem of Windows supplying a CamelCase version of a file name when it was entered lower case. Since all our web servers are 'non-windows', hitting the idiosyncrasies of these inappropriate case conversions just adds to the fun. That may not the happening these days, but cause major problems at one time! -- 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