Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100589 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 986 invoked from network); 14 Sep 2017 13:38:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Sep 2017 13:38:51 -0000 Authentication-Results: pb1.pair.com header.from=addw@phcomp.co.uk; sender-id=permerror Authentication-Results: pb1.pair.com smtp.mail=addw@phcomp.co.uk; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 78.32.209.33 as permitted sender) X-PHP-List-Original-Sender: addw@phcomp.co.uk X-Host-Fingerprint: 78.32.209.33 freshmint.phcomp.co.uk Received: from [78.32.209.33] ([78.32.209.33:52508] helo=mint.phcomp.co.uk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E2/EE-19300-9668AB95 for ; Thu, 14 Sep 2017 09:38:50 -0400 Received: from addw by mint.phcomp.co.uk with local (Exim 4.89) (envelope-from ) id 1dsULu-0007Sq-W5 for internals@lists.php.net; Thu, 14 Sep 2017 14:38:47 +0100 Date: Thu, 14 Sep 2017 14:38:46 +0100 To: internals@lists.php.net Message-ID: <20170914133846.GQ8096@phcomp.co.uk> Mail-Followup-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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <88.FC.19300.2418AB95@pb1.pair.com> Organization: Parliament Hill Computers Ltd User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants? From: addw@phcomp.co.uk (Alain Williams) On Thu, Sep 14, 2017 at 02:16:47PM +0100, Tony Marston wrote: > A minor detail. Windows followed all the previous OSes which I had > used in being case insensitive, which makes unix the odd one out. > Besides there are far more computers running Windows than unix, so > unixx should not be used as the standard. So you want a return to the horrors of code pages in file systems ? Ie how you map lower -> upper depends on how you encode characters. 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. I vote for making it case sensitive: simpler for the parser; the programmer rapidly learns that it should be 'TRUE' and not 'true' -- job done. This is what Javascript does. Many operating systems were case insensitive since your input terminal (eg AR33 Teletype) could only generate one case. But in those days it was simple since you only had one character set: ASCII or EBCDIC (translation of alphabetics between the 2 was easy, some others not so, eg: @"\£#). > >But the additional problems that case-insensitive then > >introduces may mean that all case-insensitivity has to be removed at > >that point? > > What additional problems? When billions of people are used to living > in a case-insensitive world and the only "problems" affect an > insignificantly small number in an insignificantly small number of > circumstances then the only proper solution is one that solves the > problem for the small number without messing it up for the far > larger number. That is the sort of mind-set that results in browsers accepting all sort of broken markup and making guesses on what is intended; different browsers make different guesses and render the page differently. The user then blames browser X for getting it wrong rather than the incompetent web developer who can't be bothered to check that their markup is correct. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include