Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79887 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53499 invoked from network); 23 Dec 2014 15:08:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Dec 2014 15:08:21 -0000 Authentication-Results: pb1.pair.com header.from=nf.laupretre@yahoo.fr; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=nf.laupretre@yahoo.fr; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain yahoo.fr from 212.27.42.2 cause and error) X-PHP-List-Original-Sender: nf.laupretre@yahoo.fr X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr Received: from [212.27.42.2] ([212.27.42.2:54699] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C8/A3-17517-26589945 for ; Tue, 23 Dec 2014 10:08:19 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id 9F89A4B01D8; Tue, 23 Dec 2014 16:07:02 +0100 (CET) Reply-To: To: "'Pierre Joye'" , "'Ferenc Kovacs'" Cc: "'PHP Internals'" References: <000c01d01ca0$7e70c850$7b5258f0$@yahoo.fr> In-Reply-To: Date: Tue, 23 Dec 2014 16:08:15 +0100 Message-ID: <000d01d01ec2$46f2f280$d4d8d780$@yahoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHy2TXkJ8WGpUhO4XSbKZAIVj0P4QJ7VcdxAcFBlNCcNeu1cA== Content-Language: fr X-Antivirus: avast! (VPS 141223-0, 23/12/2014), Outbound message X-Antivirus-Status: Clean Subject: RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols From: nf.laupretre@yahoo.fr ("F & N Laupretre") > De : Pierre Joye [mailto:pierre.php@gmail.com] > Anyone dying while waiting to see PHP having case sensitive symbols > handling should go ahead with a RFC. He will also have to deal with > file ops while being at it. Should they remain case insensitive? Do > manual checks to match the path actually being requested (ie. possible > on windows using meta info), or keep everything the way it is now? > These are all things we should take into account, not only "heh, let > make symbols case sensitive". What do you mean with 'case insensitive file ops' ? It's probably clear = for most of you but, unfortunately, not for me. As I'm planning an RFC on case-mismatch deprecation, I'd like to follow = your suggestion and include this topic as well.