Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100621 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3132 invoked from network); 15 Sep 2017 11:13:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Sep 2017 11:13:22 -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:16680] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E9/DC-19300-1D5BBB95 for ; Fri, 15 Sep 2017 07:13:21 -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 12:13:15 +0100 Lines: 6 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") "Andrey Andreev" wrote in message news:CAPhkiZxdVwiEDOW9XZfcADV+o1UC=SG_pc2Nw7NqU1W_gV8bNg@mail.gmail.com... > >Hi again, > >On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston >wrote: >> "Andrey Andreev" wrote in message >> news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0jg@mail.gmail.com... >>> >>> >>> Hi, >>> >>> On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston >>> wrote: >>>> >>>> >>>>> Far better that that >>>>> problem is taken away from the file system (which should be clean, >>>>> robust >>>>> and >>>>> fast) and if you want case independence put it up at the application >>>>> layer. >>>> >>>> >>>> >>>> You try telling that to the billions of Windows users who have been >>>> used >>>> to >>>> a case insensitive file system for decades. Not to mention all >>>> Microsoft >>>> software which is case insensitive. Try to take that away and billions >>>> of >>>> users will be baying for your blood. >>>> >>> >>> Billions? Do we have that statistic available? >> >> >> How many people in the world work with PCs running Microsoft Windows? >> More >> than those running alternatives. >> > >So you admit that you just made up the number? Can you show me any statistics which prove otherwise? >>> And how many of them have ever encountered case-sensitivity as a >>> concept? >> >> >> None, because they have always used case-insensitive software. >> > >And that will not change, regardless of how PHP constants work. Thus, >re-inforcing my point - that you're completely off-topic. > >>> Do they all manually type-in filenames that they want to open? If so, >>> do they for some reason name their files in all upper-case, but then >>> type in lower-case while opening? >> >> >> When searching for a file in Windows it is not necessary to now what case >> it >> was created in. When searching for a word in a file it is not necessary >> to >> now what case it was created in. TRy taking that ability away from >> Windows >> users and see what reaction you get. >> > >1. Search is a feature that goes way beyond case-sensitivity, and that >was not what I was (rhetorically) asking. >2. Unless Windows users search for filenames matching constants >declared in PHP code, this is irrelevant. > >>> Also, are we Microsoft developers? Are we trying to change Windows? >> >> >> No, but you are suggesting a change from being consistent with Windows to >> being inconsistent. >> > >It *happens* to be consistent; nobody has ever cared about whether it is or >not. >And I am not suggesting anything. I am simply pointing out the >ridiculous false-equivalences you're making. > >>> And most importantly: How do everyday Windows users have anything to >>> do with PHP developers? >> >> >> Some people are also Windows users as well as PHP developers, and if >> those >> people are told that some of the software which they use is now being >> switched from being case-insensitive to case-sensitive just because the >> programmers cannot solve a small problem which only affects a small >> number >> of character sets, then those people will not be happy. Case-insensitive >> software has been around for decades and is regarded by many users as a >> feature. It that "feature" is broken in a small number of cases then a >> proper programmer would fix that broken feature and not advocate for its >> removal just because it is more convenient than developing a fix. >> > >You do realize you just went from comparing "billions" and how >supposedly an overwhelming majority would be upset, to "some people". >And even within that intersection of audiences, you would never be >able to convince anybody here, that for some reason John Doe would >declare a constant as FOO, but then use it as Foo. > >I believe I've made my point. Please stop with the non-sense >comparisons, and talk about *constants in PHP*. You may think that this issue is limited to constants but others do not. Someone (not me) said that if constants were to be made case sensitive then the rest of the language should follow suit "just to be consistent". Someone else (not me) pointed to a bug regarding case switching when using the Turkish character set. It was suggested that one way to resolve this issue would be to avoid case switching altogether by making everything case sensitive. I suggest you look at Levi Morrison's post dated 14/09/2017 @ 17:02 which said: "For what it is worth the Turkish locale issue is on-topic. If we have case sensitivity and case insensitivity simultaneously in constants and we decide to drop one then the locale issue points towards dropping case insensitivity." 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. -- Tony Marston