Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83753 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76196 invoked from network); 25 Feb 2015 09:40:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2015 09:40:34 -0000 Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:56848] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 70/E2-62407-F889DE45 for ; Wed, 25 Feb 2015 04:40:32 -0500 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 8FDE310C040; Wed, 25 Feb 2015 09:40:28 +0000 (GMT) Date: Wed, 25 Feb 2015 09:40:28 +0000 (GMT) X-X-Sender: derick@whisky.home.derickrethans.nl To: Yasuo Ohgaki cc: Alexander Lisachenko , PHP internals list In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine From: derick@php.net (Derick Rethans) On Tue, 24 Feb 2015, Yasuo Ohgaki wrote: > On Tue, Feb 24, 2015 at 4:48 PM, Alexander Lisachenko < > lisachenko.it@gmail.com> wrote: > > > There is a draft for that: https://wiki.php.net/rfc/case-sensitivity > > (mostly empty), so I decided to ask this question in the internals > > mail list. > > > > Pros: more simple O(1) hash table checks for properties, functions, > > methods, classes without strtolower normalization on the > > engine/parser level. Consistency with unicode class names (yes, they > > are case sensitive, check http://3v4l.org/ia0pc), consistency with > > exisiting PSR0,4 standards (case sensitive mapping of class names to > > the file names) > > > > From my experience, all modern PHP framework don't use > > case-insensitive code, so chance to break anything for them is > > really low. > > > > Cons: on the extension level things aren't so good and can be some > > BC breaks (like with phpng) > > > > Possible ways: > > > > 1) Keep PHP engine case-insensitive for PHP7 > > 2) Make PHP engine case-sensitive since PHP7 with possible minor BC breaks > > in the extensions (this breaks can be easily fixed) > > 3) Add a compile-time switch, eg. --with-case-sensitivity to the > > configuration to have an ability to build PHP with sensitivity and make > > this option enabled by default since next major version (PHP>=8.0). Add > > deprecation notices in 7.x > > > > INI switch is better. Compiler switch would not work well, since user > cannot check their code easily. An INI setting that changes how syntax or code works is never *never* a good idea. It's something that many developers have no control over. To be really honest, I don't think all of the pro's hold up. For a hash check, there is no change really - the only change that is to remove the zend_tolower. Previous discussions have IIRC shown that the performance benefit is minimal. Compatibility with PSR's is also a moot point, as there are just recommendations. However, there are a few extra cons: You are going to break people's code on a large scale. I simply don't think it is worth it (again, just like when this discussion popped up every year or so for the last decade). cheers, Derick