Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83857 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2924 invoked from network); 26 Feb 2015 00:36:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2015 00:36:59 -0000 Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender) X-PHP-List-Original-Sender: francois@php.net X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr Received: from [212.27.42.2] ([212.27.42.2:36373] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AF/D0-32243-8AA6EE45 for ; Wed, 25 Feb 2015 19:36:59 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id 90E2E4B00A5; Thu, 26 Feb 2015 01:36:35 +0100 (CET) Reply-To: To: "'Pierre Joye'" , "'Dmitry Stogov'" Cc: "'Alexander Lisachenko'" , "'PHP internals list'" References: In-Reply-To: Date: Thu, 26 Feb 2015 01:36:49 +0100 Message-ID: <09d301d0515c$4ed44680$ec7cd380$@php.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIPk8nXQdC7YxKTesF5vliHaD2pywEe37LPAYpwIu6cbjkuAA== Content-Language: fr X-Antivirus: avast! (VPS 150225-3, 25/02/2015), Outbound message X-Antivirus-Status: Clean Subject: RE: [PHP-DEV] [Discussion] Last chance for case-sensitive engine From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=) Pierre, > De : Pierre Joye [mailto:pierre.php@gmail.com] > > > I case we would designed a new language I would rise two hands. > > Changing, syntax in an existent widely used language is an = additional pain > > for users. > > Technically it shouldn't be very difficult to remove support for > > case-insensitivity, and it'll even improve speed and memory = consumption, > > but I don't think it costs the compatibility break. >=20 > I fully agree and why I will vote no on that. Even if I know many > projects that won't even notice such changes. But I also have no idea > how many 1000s projects out there won't be as happy. Don't worry, I won't bother anyone with a vote at this stage. I have = started an RFC to keep a track and explore the topic but it is a complex = subject. It is even *many* more or less independent complex subjects. Anyway, some may be easier than others, for different reasons (just = personal opinions, to be confirmed in each case) : - Namespaces are relatively new. We might expect code using them to be = 'cleaner', - We can probably quite easily deprecate support (internal and userland) = for case-insensitive functions by just making null, false, and true = case-sensitive and adding new NULL, FALSE, TRUE, Null, False, and True. = Probably no need for fAlSe or tRUE :) - __halt_compiler() does not represent much but has the benefit of being = an easy case :) - magic methods are already more risky but may be imagined with some = case-sensitive aliases added. The rest is more complex, and would necessitate extensive impact = studies. Regards Fran=C3=A7ois