Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100576 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72447 invoked from network); 14 Sep 2017 09:23:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Sep 2017 09:23:52 -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:28522] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 73/F9-19300-7AA4AB95 for ; Thu, 14 Sep 2017 05:23:51 -0400 Message-ID: <73.F9.19300.7AA4AB95@pb1.pair.com> To: internals@lists.php.net References: <3D.0C.10715.383F8B95@pb1.pair.com> <09.43.19300.8E659B95@pb1.pair.com> In-Reply-To: <09.43.19300.8E659B95@pb1.pair.com> Date: Thu, 14 Sep 2017 10:23:48 +0100 Lines: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response 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") ""Tony Marston"" wrote in message news:09.43.19300.8E659B95@pb1.pair.com... > >"Levi Morrison" wrote in message >news:CAFMT4NrC43y-nL_V85qt7JgV1ohM0y4KExhB4e3mi1EjHJ0hBw@mail.gmail.com... >> >>On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston >>wrote: >>> People who think that case sensitive software is cool are deluding >>> themselves. When I started working on mainframe computers (UNIVAC and >>> IBM) >>> in the early 1970s everything was case-insensitive. This was only >>> changed by >>> people who did not understand the ramifications of their choice. >> >>Actually there are concrete bugs caused by case insensitivity. For one >>example, here is our own bugs.ph p.net report about a Turkish locale >>issue: >> >> https://bugs.php.net/bug.php?id=18556 >> >>The short summary of the issue is that when capital `I`, the ninth >>letter of the English alphabet, is lowercased in the Turkish locales >>it does not become the same `i` as it does in English but a different >>i that is not considered equal. Thus classes such as `Iterator` are >>not found in the Turkish locales. Note that this bug was fixed, and >>then there was a regression that lasted until PHP 5.5. >> >>There are other case insensitivity bugs but this Turkish one is the >>poster child and if you search around you can find many examples of >>it. >> >>Case sensitivity is thus *a correctness issue* and not a "cool"ness, >>personal preference, performance, or some other type of issue. I argue >>correctness and maintenance issues are the most important and thus if >>we change sensitivity of *any* type of symbol it should go in the >>direction of being case sensitive. Someone can disagree on what they >>value but people who think case insensitivity is not a correctness >>issue "are deluding themselves". >> >>Levi Morrison > >I'm sorry, but errors in translation from one character set to another are >insignificant when compared with the much larger problem of the same word >having diferent meanings depending on case. In the English language "info" >is the same as "Info" is the same as "INFO" is the same as "iNFO" is the >same as "iNfO" and so on. If the problem is that an English word cannot be >recognised as the same word regardless of case when switching to a >non-English character set then the issue is with switching to a non-English >character set. > >Introducing case sensitivity just for this minor bug would create more >issues than it would solve, so this bug should be solved using a different >technique . > Would this problem disappear by using UTF8 instead of the Turkish character set? If so then ten no other solution would be required. -- Tony Marston