Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100630 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22068 invoked from network); 15 Sep 2017 14:48:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Sep 2017 14:48:18 -0000 X-Host-Fingerprint: 62.31.75.76 76.75-31-62.static.virginmediabusiness.co.uk Received: from [62.31.75.76] ([62.31.75.76:9888] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DE/CF-19300-138EBB95 for ; Fri, 15 Sep 2017 10:48:18 -0400 Message-ID: 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> In-Reply-To: Date: Fri, 15 Sep 2017 15:48:13 +0100 Lines: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 62.31.75.76 Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants? From: TonyMarston@hotmail.com ("Tony Marston") "Lester Caine" wrote in message news:d97cd2e5-bd5b-4c9f-2c20-107560d5a2e5@lsces.co.uk... > >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. It may be impractical for lazy programmers, but it is not impossible. While unicode can comfortably deal with one-to-one case mappings, it does provide the means to specify one-to-many case mappings and other special cases. All it needs is for all these special cases to be identified and the "problem" is alleviated. > 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. Good idea. If certain characters cause problems when switching case then those characters should be banned. >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. I haven't, but I always take the precaution of downshifting all file names in order to avoid problems with that PITA called unix/linux. > 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! There are still inconsistencies when different browsers render the same HTML, CSS or Javascript differently. -- Tony Marston